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ABSTRACT 



A scalable access filter that is used together with others like 
it in a virtual private network to control access by users at 
clients in the network to information resources provided by 
servers in the network. Each access filter uses a local copy 
of an access control data base to determine whether an 
access request is made by a user. Changes made by admin- 
istrators in the local copies are propagated to all of the other 
local copies. Each user belongs to one or more user groups 
and each information resource belongs to one or more 
information sets. Access is permitted or denied according to 
of access policies which define access in terms of the user 
groups and information sets. The rights of administrators are 
similarly determined by administrative policies. Access is 
further permitted only if the trust levels of a mode of 
identification of the user and of the path in the network by 
which the access is made are sufficient for the sensitivity 
level of the information resource. If necessary, the access 
filter automatically encrypts the request with an encryption 
method whose trust level is sufficient. The first access filter 
in the path performs the access check and encrypts and 
authenticates the request; the other access niters in the path 
do not repeat the access check. 

14 Claims, 31 Drawing Sheets 
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TECHNIQUES FOR ELIMINATING 
REDUNDANT ACCESS CHECKING BY 
ACCESS FILTERS 

CROSS REFERENCE TO RELATED PATENT 5 
APPLICATIONS 

The present patent application claims priority from the 
provisional applications Ser. No. 60/039,542, Schneider, et 
al., Distributed Network Security, filed Mar. 10, 1997, and 
Ser. No. 60/040,262, Schneider et al. f Secure Electronic 10 
Network Delivery, also filed Mar. ,10, 1997. The present 
patent application is further one of four patent applications 
that have the same Detailed Description and assignee as the 
present patent application and are being filed on the same 
date. The four applications are: 15 
U.S. Ser. No. 09/034,507, David Schneider, et al., Dis- 
tributed Administration of Access to Information; 
U.S. Ser. No. 09/034,503, David Schneider, et al., User 

Interface for Accessing Information Resources; 2 o 
U.S. Ser. No. 09/034,576, David Schneider, et al., Secure 

Delivery of Information in a Network; and 
U.S. Ser. No. 09/034,587, David Schneider, et al., Scal- 
able Access Filter. 

BACKGROUND OF THE INVENTION 25 

1. Field of the Invention 

The invention relates generally to control of access to data 
and relates more specifically to control of access to data in 
a distributed environment. 30 

2. Description of Related Art 

The Internet has revolutionized data communications. It 
has done so by providing protocols and addressing schemes 
which make it possible for any computer system anywhere 35 
in the world to exchange information with any other com- 
puter system anywhere in the world, regardless of the 
computer system's physical hardware, the kind of physical 
network it is connected to, or the kinds of physical networks 
that are used to send the information from the one computer ^ 
system to the other computer system. All that is required for 
the two computer systems to exchange information is that 
each computer system have an Internet address and the 
software necessary for the protocols and that there be a route 
between the two machines by way of some combination of 45 
the many physical networks that may be used to carry 
messages constructed according to the protocols. 

The very ease with which computer systems may 
exchange information via the Internet has, however, caused 
problems. On the one hand, it has made accessing informa- 50 
tion easier and cheaper than it ever was before; on the other 
hand, it has made it much harder to protect information. The 
Internet has made it harder to protect information in two 
ways: 

It is harder to restrict access. If information may be 55 
accessed at all via the Internet, it is potentially acces- 
sible to anyone with access to the Internet. Once there 
is Internet access to information, blocking skilled 
intruders becomes a difficult technical problem. 

It is harder to maintain security en route through the 60 
Internet. The Internet is implemented as a packet 
switching network. It is impossible to predict what 
route a message will take through the network. It is 
further impossible to ensure the security of all of the 
switches, or to ensure that the portions of the message, 65 
including those which specify its source or destination, 
have not been read or altered en route. 



2 

FIG. 1 shows techniques presently used to increase secu- 
rity in networks that are accessible via the Internet. FIG. 1 
shows network 101, which is made up of two separate 
internal networks 103(A) aQ d 103(B) that are connected by 
Internet HI. Networks 103(A) and 103(B) are not generally 
accessible, but are part of the Internet in the sense that 
computer systems in these networks have Internet addresses 
and employ Internet protocols to exchange information. Two 
such computer systems appear in FIG. 1 as requestor 105 in 
network 103(A) and server 113 in network 103(6). 
Requestor 105 is requesting access to data which can be 
provided by server 113. Attached to server 113 is a mass 
storage device 115 that contains data 117 which is being 
requested by requestor 105. Of course, for other data, server 
113 may be the requester and requester 105 the server. 
Moreover, access is to be understood in the present context 
as any operation which can read or change data stored on 
server 113 or which can change the state of server 113. In 
making the request, requestor 105 is using one of the 
standard TCP/IP protocols. As used here, a protocol is a 
description of a set of messages that can be used to exchange 
information between computer systems. The actual mes- 
sages that are sent between computer systems that are 
communicating according to a protocol are collectively 
termed a session. During the session, Requestor 105 sends 
messages according to the protocol to server 113's Internet 
address and server 113 sends messages according to the 
protocol to requestor 105's Internet address. Both the 
request and response will travel between internal network 
103(A) and 103(B) by Internet 111. If server 113 permits 
requestor 105 to access the data, some of the messages 
flowing from server 113 to requester 105 in the session will 
include the requested data 117. The software components of 
server 113 which respond to the messages as required by the 
protocol are termed a service. 

If the owner of internal networks 103(A and B) wants to 
be sure that only users of computer systems connected 
directly to networks 103(A and B) can access data 117 and 
that the contents of the request and response are not known 
outside those networks, the owner must solve two problems: 
making sure that server 113 does not respond to requests 
from computer systems other than those connected to the 
internal networks and making sure that people with access to 
Internet 111 cannot access or modify the request and 
response while they are in transit through Internet 111. Two 
techniques which make it possible to achieve these goals are 
firewalls and funneling using encryption. 

Conceptually, a firewall is a barrier between an internal 
network and the rest of Internet 111. Firewalls appear at 
109(A) and (B). Firewall 109(A) protects internal network 
103(A) and firewall 109(B) protects internal network 103 
(B). Firewalls are implemented by means of a gateway 
running in a computer system that is installed at the point 
where an internal network is connected to the Internet. 
Included in the gateway is an access filter: a set of software 
and hardware components in the computer system which 
checks all requests from outside the internal network for 
information stored inside the internal network and only 
sends a request on into the internal network if it is from a 
sources that has the right to access the information. 
Otherwise, it discards the request. Two such access filters, 
access filter 107(A), and access filter 107(B), appear in FIG. 
1. 

A source has the right to access the requested information 
if two questions can be answered affirmatively: 
Is the source in fact who or what it claims to be? 
Does the source have the right to access the data? 
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The process of finding the answer to the first question is 
termed authentication. A user authenticates himself or her- 
self to the firewall by providing information to the firewall 
that identifies the user. Among such information is the 
following: 5 
information provided by an authentication token 
(sometimes called a smartcard) in the possession of the 
user; 

the operating system identification for the user's machine; 

and 10 
the IP address and the Internet domain name of the user's 

machine. 

The information that the firewall uses for authentication 
can either be in band, that is, it is part of the protocol, or it 
can be out of band, that is, it is provided by a separate is 
protocol. 

As is clear from the above list of identification 
information, the degree to which a firewall can trust iden- 
tification information to authenticate a user depends on the 
kind of identification information. For example, the IP 20 
address in a packet can be changed by anyone who can 
intercept the packet; consequently, the firewall can put little 
trust in it and authentication by means of the IP address is 
said to have a very low trust level. On the other hand, when 
the identification information comes from a token, the 25 
firewall can give the identification a much higher trust level, 
since the token would fail to identify the user only if it had 
come into someone else's possession. For a discussion on 
authentication generally, see S. Bellovin and W. Cheswick, 
Firewalls and Internet Security, Addison Wesley, Reading, 30 
Mass., 1994. 

In modem access filters, access is checked at two levels, 
the Internet packet, or EP level, and the application level. 
Beginning with the IP level, the messages used in Internet 
protocols are carried in packets called datagrams. Each such 35 
packet has a header which contains information indicating 
the source and destination of the packet. The source and 
destination are each expressed in terms of IP address and 
port number. A port number is a number from 1 to 65535 
used to individuate multiple streams of traffic within a 40 
computer. Services for well-known Internet protocols (such 
as HTTP or FTP) are assigned well known port numbers that 
they 'listen* to. The access filter has a set of rules which 
indicate which destinations may receive IP packets from 
which sources, and if the source and destination specified in 45 
the header do not conform to these rules, the packet is 
discarded. For example, the rules may allow or disallow all 
access from one computer to another, or limit access to a 
particular service (specified by the port number) based on 
the source of the IP packet. There is, however, no informa- 50 
tion in the header of the IP packet about the individual piece 
of information being accessed and the only information 
about the user is the source information. Access checking 
that involves either authentication of the user beyond what 
is possible using the source information or determining 55 
whether the user has access to an individual piece of 
information thus cannot by done at the IP level, but must 
instead be done at the protocol level. 

Access checking at the application level is usually done in 
the firewall by proxies. A proxy is a software component of 60 
the access filter. The proxy is so called because it serves as 
the protocol's stand-in in the access filter for the purposes of 
carrying out user authentication and/or access checking on 
the piece of information that the user has requested. For 
example, a frequently-used TCP/IP protocol is the hyper- 65 
text transfer protocol, or HTTP, which is used to transfer 
World-Wide Web pages from one computer to another such 
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computer system. If access control for individual pages is 
needed, the contents of the protocol must be inspected to 
determine which particular Web page is requested. For a 
detailed discussion of firewalls, see the Bellovin and 
Cheswick reference supra. 

While properly-done access filtering can prevent unau- 
thorized access via Internet 111 to data stored in an internal 
network, it cannot prevent unauthorized access to data that 
is in transit through Internet 111. That is prevented by means 
of tunneling using encryption. This kind of tunneling works 
as follows: when access filter 107(A) receives an IP packet 
from a computer system in internal network 103(A) which 
has a destination address in internal network 103(B), it 
encrypts the IP packet, including its header, and adds a new 
header which specifies the IP address of access filter 107(A) 
as the source address for the packet and the IP address of 
access filter 107(B) as the destination address. The new 
header may also contain authentication information which 
identifies access filter 107(A) as the source of the encrypted 
packet and information from which access filter 107(B) can 
determine whether the encrypted packet has been tampered 
with. 

Because the original IP packet has been encrypted, neither 
the header nor the contents of the original IP packet can be 
read while it is passing through Internet 111, nor can the 
header or data of the original IP packet be modified without 
detection. When access filter 107(B) receives the IP packet, 
it uses any identification information to determine whether 
the packet is really from access filter 107(A). If it is, it 
removes the header added by access filter 107(A) to the 
packet, determines whether the packet was tampered with 
and if it was not, decrypts the packet and performs IP-level 
access checking on the original header. If the header passes, 
access filter 107(B) forwards the packet to the IP address in 
the internal network specified in the original header or to a 
proxy for protocol level access control. The original IP 
packet is said to runnel through Internet 111. In FIG. 1, one 
such tunnel 112 is shown between access filter 107(A) and 
107(B). An additional advantage of tunneling is that it hides 
the structure of the internal networks from those who have 
access to them only from Internet 111, since the only 
unencrypted IP addresses are those of the access filters. 

The owner of internal networks 103(A) and 103(B) can 
also use tunneling together with Internet 111 to make the two 
internal networks 103(A and B) into a single virtual private 
network (VPN) 119. By means of tunnel 112, computer 
systems in network 103(A) and 103(B) can communicate 
with each other securely and refer to other computers as if 
network 103(A) and 103(B) were connected by a private 
physical link instead of by Internet 111. Indeed, virtual 
private network 119 may be extend ed to include any user 
who has access to Internet 111 and can do the following: 

encrypt Internet packets addressed to a computer system 
in an internal network 103 in a fashion which permits 
an access filter 107 to decrypt them; 

add a header to the encrypted packet which is addressed 
to filter 107; and 

authenticate him or herself to access filter 107. 

For example, an employee who has a portable computer 
that is connected to Internet 111 and has the necessary 
encryption and authentication capabilities can use the virtual 
private network to securely retrieve data from a computer 
system in one of the internal networks. 

Once internal networks begin using Internet addressing 
and Internet protocols and are connected into virtual private 
networks, the browsers that have been developed for the 
Internet can be used as well in the internal networks 103, and 
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from the point of view of the user, there is no difference network by a user at a client to an information resource 

between accessing data in Internet 111 and accessing it in provided by a server when there are a number of access 

internal network 103. Internal network 103 has thus become filters in the path through the network from the client to the 
an intranet, that is, an internal network that has the same user server. One solution is an access filter which has an access 

interface as Internet 111. Of course, once all of the internal 5 check confirmer that determines whether another access 

networks belonging to an entity have been combined into a filter has ^ady ma d e a determination whether the user may 

single virtual private intranet, the access control issues request the access. The access check confirmer causes the 

characteristic of the Internet arise again— except this time access filter t0 make ^ determination only if the determi- 

with regard to internal access to data. While firewalls at the nation has not been made by another access filter. Having 

points where the internal networks are connected to Internet 10 ma d e me determination, the access filter adds authentication 

111 are perfectly sufficient to keep outsiders from accessing information to the access request indicating that the access 

data in the internal networks, they cannot keep insiders from fii ter nas made the determination. In one embodiment, the 

accessing that data. For example, it may be just as important authentication information is inherent in the use of encryp- 

to a company to protect its personnel data from its employ- t j on destined for another access filter in the VPN, where all 

ees as to protect it from outsiders. At the same time, the 15 0 f me acC ess filters in the VPN authenticate each other via 

company may want to make its World Wide Web site on a certificates signed by mutually trusted certificate authorities, 

computer system in one of the internal networks 103 easily Encryption may be by one of several methods. The access 

accessible to anyone who has access to Internet 111. fti ter mat ^ handles a request for data selects a method 

One solution to the security problems posed by virtual wn ich is sufficient for a sensitivity level of the resource 

private intranets is to use firewalls to subdivide the internal 20 being accessed. After encrypting the access request, the 

networks, as well as to protect the internal networks from otner acceS s filter adds authentication information as 

unauthorized access via the Internet. Present-day access described above 

filters 107 are designed for protecting the perimeter of an , n ^ Qf ^ inveQti ^ q[ ^ ^ 

interna network from unauthorized access, and there is ^ has fl ^ of access contnjl mformation ^ ^ 

typically only one access filter 107 per Internet connect™. * access checkw ^ uges me ^ tQ whethef 

If access filters are to be used wuhin the internal networks, ^ ^ access ^ fesom(x ^ access ^ 

there wul be many more of them, and virtual private m ^ for mald ch fa ^ ^ ^ 

networks that use multiple present-day access filters 107 are a cfa propagator for pr0 pag a ting the changes to others of 

not easily scalable, that in virtual private networks with ^ ^ of access fiUels Included ^ ^ ^ of 

small numbers of access filters, me access filters are not a x ^ access ^ information mdicating 

senous burden; in networks with large numbers of access wh(Jther a ^ yen ^ make a ch m a determined 

filters, they are Among the problems posed by present-day of me ^ ^ access information also 

access filters when they are present in large numbers in a ^ & ^ wfao hag ^ rf fat ^ make a ch ^ ^ 

virtual private network are the followmg: predetermined part of the local copy to delegate that right to 

Present-day access filters are designed to be centrally- 35 anome r user 

administered by a small number of data security ^ . , . , , - , .... 

a .u — u r en ■ Other objects and advantages of the invention will be 

experts. As the number of access filters increases, J , . • . . 

* 1 j • • « ♦ ■ u * 1 * apparent to those skilled m the arts to which the invention 

central administration becomes too slow, too rr . , . „ . ^ , ^ 

expensive, and too error-prone. P 6r J lalns u F° n 1*™*°% ^ following Detailed Description 

„ , -1 , . . and Drawmg, wherem: 

Present-day access filters are designed on the assumption 40 

that there are only a small number of access filters BRIEF DESCRIPTION OF THE DRAWING 
between the source and destination for data. Where 

there are many, the increase in access time and the FIG. 1 is an overview of techniques used in prior art to 

reduction in access speed caused by the filters becomes control access of information via the Internet; 

important. 45 FIG. 2 is an overview of a VPN that uses access filters 

Present-day access filters are designed on the assumption incorporating the techniques disclosed herein; 

that the Internet side of the filter is completely insecure FIG. 3 is an overview of an access control database that 

and the internal network side of the filter is completely is used in the access filters; 

secure. In fact, both kinds of networks offer varying mQ 4 shows access chcc]dng and tunneling in a VPN that 

degrees of security Because security adds overhead, 50 ^ access fihers i^o^ me techniques disclosed 

the access filter should neither require nor provide more herein* 

than is necessary. ^ shows access by a "roamer" to information in the 

Present-day access filters, where they use encryption, ypjsj. 

require that each access filter know encryption keys for ' , . , • . * . 

each other access filter. Large numbers of access filters 55 FIG. 6 is a table used in defining the relationship between 

require substantial duplicated effort in key mainte- sensitivity and trust levels and authentication and encryption 

nance. techniques; 

Present-day access filters do not provide any mechanism mG - 7 is an example of the application of SEND; 

for giving the user a view of the information resources FIG. 8 is a flow chart of the policy creation process; 

that corresponds to the user's access rights. 60 FIG. 9 shows a display used to define user groups; 

What is needed if intranets and virtual private networks pic. 10 shows a display used to define information sets; 

are to achieve their full promise is access filters that do not m ~ , , , . , r - 

, . r _ , . ... FIG. 11 shows a display used to define access policies; 

present the above problems for scalability. .„ ^ , ,. , , „. 

FIG. 12 shows a display used to define an access filter 

SUMMARY OF THE INVENTION 65 203; 

The claims attached to the present application describe FIGS. 13 A, 13B are a schema of the part of access control 

solutions to the problem of speeding up access across a database 301 that defines user groups; 
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FIG. 14 is a schema of the part of access control database problems will immediately arise. Access filters 203 avoid 

301 that defines information sets; these problems because they are designed according to the 

FIG. 15 is a schema of the part of access control database following principles: 

301 that defines sites in the VPN and the servers, services, Distributed access control database. Each access filter 203 

and resources at each site* 5 has its own copy of the access control database used to 

FIGS. 16A, 16B are schema of the part of access control 0011,101 ^* fa WN 201 " 

j t , - n i i- • one copy of the database are propagated to all other 

database 301 that defines policies; M *„ 

copies. 

FIGS 17A, 17B 17C are a schema of the part of access Distributed administration. Any number of administrators 

control database 301 that defines servers; ^ may ^ delegated responsibility for subsets of the 

FIG. 18 shows the display used in the IntraMap interface; system. All administrators may perform their tasks 

FIG. 19 shows how changes are made to access control simultaneously, 

database 301; Distributed access control. Access control functions are 

FIG. 20 is a detailed block diagram of the architecture of performed at the near-end access filter 203. That is, the 

an access filter 203; 15 first access filter 203 in the path between a client and 

FIG. 21 is a diagram of the structure of an MMF file 2303; tne se^r determines if the access is allowed and 

FIG. 22 is a diagram of a mess age sent using SKIP; subsequent access filters in the path do not repeat the 

FIGS. 23A, B, and C are a table of the MMF files p "* CSS C ^ cks m f* b £ the aCCCSS fil f; „ 

employed in a preferred embodiment; End-to-end encryption. Encr^tion occurs between the 

„ A . ' . r , , near-end access filter and the furthest encryption end- 

HG. 24 is a diagram of an implementation of the Intra- 20 ^ possible , en dpoint is either the information 

Map interface; and itself or me f ar . e nd access filter 203— the one 

FIG. 25 is a diagram illustrating delegation in VPN 201. last in the route from client to server. Dynamic tunnels 

The reference numbers in the drawings have at least three are created based on current network routing conditions 

digits. The two rightmost digits are reference numbers Adaptive encryption and authentication. Variable levels of 

within a figure; the digits to the left of those digits are the 25 encryption and authentication requirements are applied 

number of the figure in which the item identified by the to traffic passed through the VPN, based on the sensi- 

reference number first appears. For example, an item with tivity of the information being transmitted, 

reference number 203 first appears in FIG. 2. All of these aspects of the design will be discussed in 

more detail below. 

DETAILED DESCRIPTION 30 It s h 0 uld be pointed out at this point that access filter 203 

The following Detailed Description will first provide an may be implemented in any fashion which ensures that all 

overview of access filters that are easily scalable, of how references to data in VPN 201 which are made by users who 

they are used to control access in intranets, and of how they may not be authorized to access that data go through an 

can be used to construct virtual private networks. access filter 203. In a preferred embodiment, access filter 

Thereupon, the Detailed Description will provide details of 35 203 is implemented on a server and runs under the Windows 

the access control database used in the filters, of the manner NT® operating system manufactured by Microsoft Corpo- 

in which it is changed and those' changes are distributed ration. In other embodiments, access filter 203 may be 

among the filters, and of the manner in which an individual implemented as a component of an operating system and/or 

filter controls access. rnay be implemented in a router in VPN 201. 

A Network with Access Filters that do not Interfere with 40 Distributed Policy Database: FIG. 3 

Scalability: FIG. 2 Each access filter 203 has a copy of an access control 

FIG. 2 shows a virtual private network (VPN) 201 in database 301 that holds all data relevant to access control in 

which access to data is controlled by access filters that are VPN 201. One access filter, shown as access filter 203(a) in 

designed to avoid the problems posed by multiple access FIG. 2, has a master copy 205 of access control database 

filters. VPN 201 is made up of four internal networks 103 45 301. Because of this, access filter 203(a) is termed the 

which are connected to each other by Internet 121. Also Master Policy Manager. The master copy 205 is the one that 

connected to VPN 201 via Internet 121 is a roamer 217, that is used to initialize new access filters 203 or replace a 

is, a computer system which is being used by a person who damaged access control database 301. The backup for the 

may access data in intranet 201, but is connected to the master policy manager computer is access filter 203(b). 

internal networks only by Internet 121. Each internal net- 50 Backup 207 is a mirror image of master copy 205. Report 

work 103 has a number of computer systems or terminals manager 209, finally, includes software for generating 

209 belonging to users and a number of servers 211 which reports from the information in access control database 301 

contain data that may be accessed by users at systems or and from logs obtained from all other access filters 203. Any 

terminals 209 or by a user at roamer 217. However, no copy of access control database 301 may be altered by any 

computer system or terminal 209 or roamer 217 is connected 55 user who has the access required to do so; as will be 

directly to a server 211; instead, each is connected via an described in more detail later, any such alteration is propa- 

access filter 203, so that all references made by a user at a gated first to master policy manager 205 and then to all of 

user system to a data item on a server go through at least one the other access filters 203 in virtual private network 201. 

access filter 203. Thus, user system 209(i) is connected to FIG. 3 is a conceptual overview of access control database 

network 213(i), which is connected to access filter 203(a), 60 301. The primary function of the database is to respond to an 

while server 211(f) is connected to network 215(/), which is access request 309 from access filter 203 which identifies a 

also connected to access filter 203(a), and any attempt by a user and an information resource with an indication 311 of 

user at user system 209(i) to' access data on server 211(*) whether the request will be granted or denied. The request 

goes through access filter 203(a), where it is rejected if the will be granted if both of the following are true: 

user does not have the right to access the data. 65 The user belongs to a user group which data base 301 

If VPN 201 is of any size at all, there will be a substantial indicates may access an information set to which the 

number of access filters 203, and consequently, scaling information resource belongs; and 
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the request has a trust level which is at least as high as a 
sensitivity level belonging to the information resource. 
Each user belongs to one or more of the user groups and 
each information resource belongs to one or more informa- 
tion sets; if none of the user groups that the user belongs to 5 
is denied access to an information set that the resource 
belongs to and any of the user groups that the user belongs 
to is allowed access to any of the information sets that the 
information resource belongs to, the user may access the 
information resource, provided that the request has the 10 
requisite trust level. 

The sensitivity level of a resource is simply a value that 
indicates the trust level required to access the resource. In 
general, the greater the need to protect the information 
resource, the higher its sensitivity level. The trust level of a 15 
request has a number of components: 

the trust level of the identification technique used to 
identify the user; for example, identification of a user 
by a token has a higher trust level than identification of 
the user by IP address, 20 
the trust level of the path taken by the access request 
through the network; for example, a path that includes 
the Internet has a lower trust level than one that 
includes only internal networks. ^ 
if the access request is encrypted, the trust level of the 
encryption technique used; the stronger the encryption 
technique, the higher the trust level. 
The trust level of the identification technique and the trust 
level of the path are each considered separately. The trust 3Q 
level of the path may, however, be affected by the trust level 
of the encryption technique used to encrypt the access 
request. If the request is encrypted with an encryption 
technique whose trust level is higher that the trust level of a 
portion of the path, the trust level of the portion is increased 35 
to the trust level of the encryption technique. Thus, if the 
trust level of a portion of a path is less than required for the 
sensitivity level of the resource, the problem can be solved 
by encrypting the access request with an encryption tech- 
nique that has the necessary trust level. ^ 

The information contained in database 301 may be 
divided into five broad categories: 

user identification information 313, which identifies the 
user; 

user groups 315, which defines the groups the users 45 
belong to; 

information resources 320, which defines the individual 
information items subject to protection and specifies 
where to find them; 

information sets 321, which defines groups of information 50 
resources; 

trust information 323, which specifies the sensitivity 
levels of information resources and the trust levels of 
user identifications and network paths; and 55 

policy information 303, which defines access rights in 
terms of user groups and objects in VPN 201. 

Policy information is further divided into access policy 
307, administrative policy 305, and policy maker policy 
306. 60 

access policy 307 defines rights of access by user groups 
to information sets; 

administrative policy 305 defines rights of user groups to 
define/delete/modify objects in VPN 201. Among the 
objects are access policies, information sets, user 65 
groups, locations in VPN 201, servers, and services; 
and 
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policy maker policy 306 defines rights of user groups to 
make access policy for information sets. 

The user groups specified in the administrative policy and 
policy maker policy portions of database 301 are user groups 
of administrators. In VPN 201, administrative authority is 
delegated by defining groups of administrators and the 
objects over which they have control in database 301. Of 
course, a given user may be a member of both ordinary user 
groups 317 and administrative user groups 319. 
Identification of Users 

User groups identify their members with user identifica- 
tion information 313. The identification information identi- 
fies its users by means of a set of extensible identification 
techniques. Presently, these identification techniques include 
X.509 certificates, Windows NT Domain identification, 
authentication tokens, and IP address/domain name. The 
kind of identification technique used to identify a user 
determines the trust level of the identification. 

Where strong identification of a user or other entity that 
an access filter 203 communicates with is required, VPN 201 
employs the Simple Key Management for Internet Protocols 
(SKIP) software protocol, developed by Sun Microsystems, 
Inc. The protocol manages public key exchange, authenti- 
cation of keys, and encryption of sessions. It does session 
encryption by means of a transport key generated from the 
public and private keys of the parties who are exchanging 
data. Public keys are included in X.509 certificates that are 
exchanged between SKIP parties using a separate protocol 
known as the Certificate Discovery Protocol (CDP). A 
message that is encrypted using SKIP includes in addition to 
the encrypted message an encrypted transport key for the. 
message and identifiers for the certificates for the source and 
destination of the data. The recipient of the message uses the 
identifiers for the certificate of the source of the message to 
locate the public key for the source, and uses its keys and the 
source's public key to decrypt the transport key and uses the 
transport key to decrypt the message. A SKIP message is 
self-authenticating in the sense that it contains an authenti- 
cation header which includes a cryptographic digest of the 
packet contents and modification of any kind will render the 
digest incorrect. For details on SKIP, see Ashar Aziz and 
Martin Patterson, Simple Key-Management for Internet Pro- 
tocols (SKIP). 

In VPN 201, SKIP is also used by access filters 203 to 
identify themselves to other access filters 203 in the VPN 
and to encrypt TCP/IP sessions where that is required. 
Access filters 203 can also use the certificates for the SKIP 
keys to identify users when they are performing access 
checks. Such an identification is particularly trustworthy and 
has a correspondingly high trust level. One use for such 
identification by mean of certificate is for trustworthy iden- 
tification of a "roamer" 217. The X.509 certificates can be 
used for user identification because they relate the key 
information to information about the user. 

Access filter 203 uses the following fields of information 
from the certificates: 

Expiration Date. The date after which the certificate is 
invalid. 

Public Key. The public half of a public-private key pair, 
as used in the SKIP-based cryptography that Conclave 
uses. 

Certificate Authority Signature. The distinguished name 
associated with the authority that issued the certificate. 

Serial Number for the certificate 

Subject name, the name of the entity the certificate was 
issued to. 
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The subject name includes the following subfields (the user group may be defined as including a Hardware Engi- 
value in parentheses is the common abbreviation for the neers user group, a Software Engineers user group, and a 
field): Sales Engineers user group. Similarly, the engineering data 
Common Name (CN). The given name of the subject, for information set may be defined as including a hardware 
example, John Q. Public. s engineering data information set, a software engineering 
Country (C). The country in which the subject resides. data information set, and a sales engineering data informa- 
Country codes are 2-letter codes specified in the X.509 tion set. Access rights are inherited within hierarchies of user 
specification. groups. Thus, a user who belongs to the Hardware Engineers 
Locality (L). The location at which the subject resides. user group also automatically belongs to the Engineers user 
This is usually the city in which the subject resides, but io group for access checking purposes. Access rights are simi- 
can be used for any location-related value. i ar i y inherited within hierarchies of information sets. An 
Organization (O). The organization to which the subject information resource that belongs to the hardware engineer- 
belongs. This is usually the organization's name. i ng information set also automatically belongs to the engi- 
Organizational Unit (OU). The organizational unit for the neering data information set for access checking purposes, 
subject. This is usually the department for the subject, 15 Thus, if there is an access policy that gives Engineers access 
for example, "sales". The X.509 certificate allows up to t0 engineering data, any user who is a member of one of the 
four of these fields to exist. three user groups making up Engineers may access any 
A Certificate Authority used with access filters 203 issues ^^0,1 res0 urce that belongs to any of the three infor- 
certificates with all of these fields. Further, the four OU mation ^ makin engineering data. The use of inher- 
fields can be used to define additional categories. The M ^ ^ ^ definitions of ^ ^ MolmalioB sets 
information used to describe a user in a certificate is avaJ- ^ s 
able to the administrators of data base 301 for use when & . J , . t . , t . - n f _ . t . . 
defining user groups. If the information in the certificates re <l mrcd m "f 88 cont ' 01 database ^. For ins *™*> m the 
properly reflects the organizational structure of the above exam P le > a . sin S le ^ f 0 ^ S ives f 11 en gf eere 
enterprise, a certificate will not only identify the user, but access to aU engmeenng data. Inheritance also makes it 
show where the user fits in the enterprise's organization and 25 possible to define virtually all access policies m terms of 
to the extent that the user groups in data base 301 reflect the allowing access. Continuing with the above example, if 
organizational structure, the user groups that the user tnere is a user & 0Xi P salespeople that does not belong to 
belongs to. Engineers and there is an access policy that gives that user 
As will be explained in more detail later, one way in g rou P access to sales engineering data, a user who is a 
which members of user groups may be defined is by cer- 30 member of salespeople will be able to access sales engi- 
tificate matching criteria which define the values of the fields neering data, but not software engineering data or hardware 
which a certificate that belongs to a member of a given user engineering data. 

group must have. The certificate matching criteria can be A user may of course belong to more than one user group 

based on as few or as many of the above fields as desired. and an information resource may belong to more than one 

For example, the certificate matching criteria for the Engi- 35 information set. There may also be different access policies 

neering user group might be the organization field and an f° r th e various user groups the user belongs to and the 

organization unit field specifying the engineering depart- various information sets the information resource belongs 

ment. Other information that identifies a user may be used to. When faced with multiple access policies that apply to 

to define members of user groups as well. toe usct an d to the information resource that the user is 

Information Sets 40 seeking to access, access filter 203 applies the policies in a 

Information sets hold collections of individual informa- restrictive, rather than permissive way: 

tion resources. A resource may be as small as an individual If multiple policies allow or deny a user group's access to 

WWW page or newsgroup, but most often it will consist of an information set, policies that deny access prevail, 

a Web directory tree and its contents, FTP accounts, or major if a particular user is a member of multiple user groups, 

Usenet news categories. Two information sets, 2190) and 45 and multiple policies allow or deny access to the 

(k), are shown in one of the servers of FIG. 2. While it is information set, policies that deny access prevail, 

completely up to the administrators of access control data- what user groups a user belongs to may vary according to 

base 301 to determine what information is included in an the mode of identification used to identify the user. Thus, if 

information set, the information in a given set will generally n0 access policies apply for the user groups that the user 

be information that is related both topically and by intended 50 belongs to according to the modes of identification that the 

audience. Example information sets for a corporation might user has thus far provided to access filter 203, access filter 

be HR policies, HR Personnel Records, and Public Infer- 203 may try to obtain additional identification information 

matlon - and determine whether the additional identification infor- 

Access Policy 307 mation places the user in a user group for which there is a 

Conceptually, access policy 307 consists of simple state- 55 policy ^ga^g me reS ource. Access filter 203 may obtain 

ments of the form: the additional identification information if: 

The user has installed the User Identification Client 
^ (software that runs on the user's machine and provides 

Engineers allowed access to engineering data 60 identification information about the user to access filter 

Internet allowed access to public web site 203). 

~~ — — — — The UIC is currently running on the user's machine. 

The first column specifies user groups; the last column The user has enabled his UIC to pop-up for further 

specifies information sets. The middle column is the access authentication. (The user has a check box that enables 

policy — allow or deny. 65 this feature.) 

Database 301 permits hierarchical definition of both user If all of these requirements are true, then access filter 203 

groups and information sets. For example, the Engineers will force the user's UIC to pop-up and ask for further 



09/13/2004, EAST Version: 1.4.1 



6,1< 

13 

identification information. Any identification information 
that the user supplies is saved. After each new piece of user 
identification information, access filter 203 performs the 
same evaluation process, popping up the UIC window until 
identification information is obtained that places the user in 
a user group for which there is an access policy that permits 
or denies access or until the user gives up on his or her 
request. 

Administrative policies 305 

The administrative policies 305 implement administration 
of objects in VPN 201 's access control system. Included in 
the objects are user groups, information sets, access policies, 
and what are termed herein available resources, that is, the 
services, servers, access filters, and network hardware mak- 
ing up VPN 201. An object is administered by one or more 
administrative user groups. A member of an administrative 
user group that administers a given object may modify the 
object and its relationship to other objects and may make 
administrative policy for the object. As will be explained in 
more detail later, the fact that a member of an administrative 
user group that administers an object may make adminis- 
trative policy for the object makes it possible for the member 
to delegate administration of the object. For example, a 
member of an administrative user group that administers a 
Hardware Engineers user group may make an administrative 
policy that gives administration of the Hardware Engineers 
to a Hardware Engineering Administrator user group, 
thereby delegating administration of Hardware Engineers to 
Hardware Engineering Administrator. It should be noted that 
the right to administer an information set is separate from the 
right to make access policy for the information set. The fact 
that a user group has the right to make access policy 
concerning an information set does not give the user group 
the right to make administrative policy for the information 
set, and vice-versa. When an access filter 203 is first set up, 
a single built-in security officer user group has administra- 
tive authority over all of the objects in VPN 201 and over 
policy maker policy 306. 
Inheritance with administrative policy 

Inheritance works with administrative policy the same 
way that it does with access policy. The user groups, 
information sets, and available resources to which admin- 
istrative policies are directed are hierarchically organized: 
Within the user groups, user groups that are subsets of a 
given user group are at the next level down in the hierarchy 
of user groups from the given user group. The same is the 
case with information sets. Inheritance applies within the 
hierarchy in the same fashion as with access policy. Thus, 
within the user group hierarchy an administrative user who 
controls a user group also controls all subsidiary, contained 
user groups. Similarly, with the information set hierarchy an 
administrative user who controls the information set also 
controls all subsidiary, contained information sets and an 
administrative user who controls access policy for an infor- 
mation set also controls access policy for all contained 
information sets. 

There is further a natural hierarchy of available resources. 
For example, one level of the hierarchy is locations. Within 
a given location, the servers at that location form the next 
level down, and within a server, the services offered by the 
service form the next level. The administrative user group 
that has control of any level of the available resources tree 
also controls all lower levels. For example, the administrator 
(s) to whom an administrative policy gives control of an 
access filter 203 has administrative rights to all servers 
beneath that site, all services running on those servers and all 
resources supported by those services. 



)5,027 

14 

Delegation: FIG. 25 

Delegation is easy in VPN 201 because the members of 
the administrative user group that administers an object may 
both modify the object and make administrative policy for it. 

5 For example, if an adrninistrative user group administers an 
information set, it can divide the information set into two 
subsets and make new administrative policies which give 
each of two other user groups administrative authority over 
one of the two subsets. 

10 FIG. 25 gives an extended example of delegation. In FIG. 
25, user groups and other objects are represented by circles; 
policy maker policy is represented by a square box; policy 
relationships are expressed by different kinds of arrows: a 
solid arrow for administrative policy, a dotted arrow for 

15 policy maker policy, and a dashed arrow for access policy. 
The part of the figure labeled 2501 shows the situation when 
access filter 203 is being set up: the built-in Security Officer 
user group 2503 has administrative authority over all of the 
built-in objects 2505 and over policy maker policy 2507. 

20 Members of Security Officer user group 2503 use their 
administrative authority to make subsets of objects 2505, 
rearrange the object hierarchies, and set up policy maker 
policy 2507. 

One result of the activity of Security Officer user group 
25 2503 's activity is seen in the section of FIG. 25 labeled 

2508. A member of Security Officer user group 2503 has set 
up an Engineering Administrators administrative user group 

2509, an Engineers user group 2511, and an Engineering 
Data information set 2513 and has given Engineering 

30 Administrators administrative authority over Engineers and 
Engineering Data. The member of Security Officer has also 
set up policy maker policy 2507 so that Engineering Admin- 
istrators has the right to make access policy for Engineering 
Data, as shown by dotted arrow 2510. A member of Engj- 

35 neering Administrators has used that right to make access 
policy that permits members of Engineers 2511 to access 
information in Engineering Data 2513, as shown by dashed 
arrow 2512. The member of Security Officer has thus 
delegated the administrative authority over Engineers 2511, 

40 Engineering Data 2513, and over access to Engineering Data 
to Engineering Administrators 2509. 

Security Officer 2503 of course still has administrative 
authority over Engineering Administrators and can use that 
authority for further delegation. An example is shown at 

45 2517. A member of Security Officer 2503 has divided 
Engineering Administrators into two subsets: Engineering 
Personnel Administrators (EPA) 2519 and Engineering Data 
Administrators (EDA) 2521. The members of these subsets 
inherit administrative rights over Engineers 2511 and Engj- 

50 neering Data 2513 from Engineering Administrators 2509. 
The members of EPA 2519 and EDA 2521 use these 
administrative rights to delegate administrative authority 
over Engineers 2511 to Engineering Personnel Administra- 
tors 2519 and administrative authority over Engineering 

55 Data 2513 to Engineering Data Administrators 2521. The 
members of EPA 2519 and EDA 2521 have further used their 
right to make access policy for Engineering Data 2513 to 
change the access policy so that access policy for Engineer- 
ing Data is made by Engineering Data Administrators 2513, 

60 as shown by dotted arrow 2523, instead of by Engineering 
Administrators, thereby delegating that function to Engi- 
neering Data Administrators. 

Members of Engineering Personnel Administrators and 
Engineering Data Administrators can now use their admin - 

65 istrative rights over Engineers, Engineering Data, and access 
policy for Engineering Data to refine access to Engineering 
Data. For example, a member of Engineering Personnel 
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Administrators might subdivide Engineers into Software 
Engineers and Hardware Engineers and a member of Engi- 
neering Data Administrators might subdivide Engineering 
Data into Hardware Engineering Data and Software Engi- 
neering Data. That done, a member of Engineering Data 
Administrators might replace the access policy giving Engi- 
neers access to Engineering Data with access policies that 
give Software Engineers access to Software Engineering 
Data and Hardware Engineers access to Hardware Engineer- 
ing Data. 

In summary, it may be said that the administrators who 
have control over a user group are responsible for correctly 
defining membership in the user group; they may delegate 
any part of this responsibility to other administrators. 
Similarly, administrators who have control over an infor- 
mation set are responsible for correctly including informa- 
tion resources into the information set; they may delegate 
any part of this responsibility to other administrators. The 
latter administrators must of course also be administrators 
for some available resource from which the information 
being added to the information set may be obtained. Admin- 
istrators of available resources carry responsibility for over- 
all network and security operation. Likewise, they may 
delegate their responsibilities. Policy maker administrators, 
finally, hold the ultimate control over access to information. 
They alone may create access policies related to specific 
information sets. In a sense, the policy makers determine the 
overall information sharing policy for the enterprise. Admin- 
istrators for the user groups, information sets, and available 
resources then determine the particulars of implementation. 
Access Control using Filters 203 and Database 301: FIG. 4 

As shown in FIG. 2, an access filter 203 has a position in 
VPN 201 which puts it between the client from which the 
user is requesting access to the information resource and the 
server upon which the information resource resides. The 
access filter 203 is thus able to control access by the user to 
the resource by interceding in the communication between a 
user and a service on the server which is able to provide the 
user with access to the information resource. In order for the 
user to gain access to the information resource, a session 
must be established between the user and the service. In the 
present context, the term session is defined liberally, to 
include well-behaved connectionless protocols. When an 
access filter 203 observes an attempt by a user to initiate a 
session with a service, it determines whether access should 
be permitted. It does so from the known identity of the user, 
the information resource to which the information is being 
accessed, the sensitivity level of the information, and the 
trust levels of the user identification, of the path between the 
user and the service, and of any encryption technique used. 

FIG. 4 shows how a session can involve more than one 
access filter 203. Session 402 shown in FIG. 4 involves five 
access filters 203, numbered 403(1 ... 5) in the Figure. 
Access filters 203 are designed such that the decision 
whether to grant a user access to an information resource 
need only be made in one of the access filters 203. The key 
to this feature of access filters 203 is their ability to authen- 
ticate themselves to each other. SKIP is used to do this. 
Every access filter 203 has an X.509 certificate that binds the 
access filter 203 's keys to the access filter's name and is 
signed by the Certificate Authority for the VPN. Each access 
filter 203 has the names and IP addresses of all of the other 
access filters in VPN 201 in data base 301, and upon arrival 
of a session that is encrypted using SKIP, each access filter 
uses the Subject Name from the certificates as described 
above in the discussion of SKIP to determine whether 
SKIP-encrypted network traffic is from another access filter 
203 in VPN 201. 
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If the access filter receiving the session is not the desti- 
nation of the session, (that is, the access filter functions 
simply as an IP router along the path), the access filter 
merely verifies from data base 301 that the destination IP 

s address is the IP address of some other access filter 203 in 
VPN 201. If that is the case, then the session is allowed to 
pass without additional checking. When the request reaches 
the last access filter 203, the last access filter 203 uses SKIP 
to decrypt the request, to confirm that the request was indeed 

10 checked by the first access filter 203, and to confirm that the 
request has not been modified in transit. 

Thus, in FIG. 4, access filter 403(1) uses its own copy of 
access control database 301 to determine whether the user 
who originates a session has access to the information 

15 resource specified for the session. If access filter 403(1) so 
determines, it authenticates the session's outgoing messages 
and encrypts them as required to achieve the proper trust 
level. Access filters 403(2 ... 5) then permit the session to 
proceed because the session is from access filter 403(1) and 

20 has been encrypted with SKIP and neither decrypt the 
messages nor check them using their own copies of access 
control database 301. Access filter 403(5) then decrypts the 
messages, confirms that they were encrypted and therefore 
checked by access filter 403(1), and if the messages are 

25 intact, forwards them to server 407 that contains the desired 
resource. Messages in the session which pass between server 
407 and user system 401 are treated in the same way, with 
access filter 403(5) encrypting them if necessary, access 
filters 403(2 ... 4) passing them through on the basis of the 

30 authentication by 403(5), and access filter 403(1) passing the 
message on to system 401 on the basis of the authentication 
and decrypting the message if necessary. 

What this technique effectively does is to make a tunnel 
405 for the session between access filter 403(1) and access 

35 filter 403(5), and because of the tunnel, only the access filter 
403 closest to the client needs to do decryption, access 
checking, and reencryption. Moreover, the tunnel is equally 
secure in the internal networks and in Internet 121. In a large 
VPN, access filter 403(1) is in the best position to check 

40 access, because it has access to the most detailed informa- 
tion about the user who originates the session. The technique 
of performing the access check at the first access filter 401 
further distributes the access control responsibility evenly 
across the VPN, allowing it to scale to any size. 

45 End-to-End Encryption: FIG. 5 

Tunnel 405 of FIG. 4 extends only from access filter 
403(1) to access filter 403(5); the messages of the session are 
unencrypted between system 401 employed by the user and 
access filter 403(1) and again between access filter 403(5) 

50 and server 407 that contains the information resource. In the 
case of extremely sensitive information, authentication and 
encryption may be needed from the near end access filter to 
the end of the path through the network, namely between 
system 403(1) and server 407. 

55 FIG. 5 shows how this is accomplished using access filters 
203. Within the VPN, authentication and encryption may be 
used with any client system 401 or 503 or any server system 
407 in addition to access filters 203. When a client computer 
utilizes encryption, it uses SKIP to authenticate the session 

60 and encrypt it using a shared secret that is shared between 
the client computer and a selected access filter 203 and then 
sends the encrypted message to the selected access filter 203, 
thereby effectively establishing a tunnel between the client 
and the selected access filter 203 and making the selected 

65 access filter 203 the first access filter 203 for purposes of 
access checking. At the first access filter 203, the messages 
are decrypted and access checking is done. Since SKIP 
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makes available the user's certificate along with the 
encrypted message, the user's authenticated identity can be 
used for access checking. If the access is permitted, "the 
message is once again encrypted and sent to access filter 
403(5) nearest server 407, which decrypts it. If data base 301 
contains a SKIP name and encryption algorithms for server 
407, access filter 403(5) retrieves the certificate for server 
407 if necessary and uses SKIP to reencrypt the session as 
required for server 407. Otherwise, access filter 403(5) 
simply sends the message to server 407 in the clear. If the 
message was reencrypted for server 407, server 407, finally, 
receives the encrypted message and decrypts it. The access 
filters 203 intermediate to the first access filter 203 and last 
access filter 203 simply note that the message is from 
another access filter and is encrypted with SKIP and pass the 
message on, as described above. When server 407 retrieves 
the information resource, it either sends it in the clear to 
access filter 403(5) or encrypts the message containing the 
resource with the key for access filter 403(5). The process of 
decrypting and encrypting described above is then per- 
formed in reverse, pairwise, from server 407 to access filter 
403(5), from access filter 403(5) to access filter 403(1), and 
finally from access filter 403(1) to the original client system, 
which decrypts it. 

The effect of this technique is to construct a tunnel on the 
path between the client and the server which runs from the 
access filter 203 on the path which is nearest to the client to 
the access filter 203 on the path which is nearest to the 
server If the client is capable of encryption and decryption, 
the tunnel can be extended from the access filter nearest the 
client to the client and if the server is capable of encryption 
and decryption, the tunnel can be similarly extended to from 
the access filter nearest the server to the server. Once the first 
access filter 203 in the path has been reached and has 
authenticated the session, no further encryption or decryp- 
tion is required until the access filter 203 nearest the server 
has been reached. Moreover, access control database 301 in 
each access filter 203 contains all of the necessary identifi- 
cation and certification information for the client, the server, 
and the access filters 203 in the route. An advantage of the 
end-to-end encryption technique just described is that it 
distributes encryption load throughout the network, rather 
than concentrating it at the access filters connecting the VPN 
to the Internet, and thereby enhances scalability. 

FIG. 5 shows how the technique works with a session 501 
that originates with a roamer, that is, a client 503 whose 
connection to the VPN is via Internet 121. Roamer 503 is 
equipped with SKIP, as is target server 407 on an internal 
network. When SKIP was configured in the roamer, it was 
given the certificate for access filter 403(3) and access filter 
403(3) was given the certificate for the roamer. When 
roamer 503 sends a message belonging to the session, it 
addresses the message to server 407 and encrypts it using a 
transport key which it shares with access filter 403(3). The 
message is thus tunneled via tunnel 505 to access filter 
403(3). There, access filter 403(3) decrypts the session, 
performs the access check, and reencrypts it using a trans- 
port key for access filter 403(5). The subsequent access 
filters 403 in the path allow the session through because it is 
authenticated by access filter 403(3), thus providing tunnel 
507 to at least access filter 403(5). If target server 407 is 
SKIP-equipped, access filter 403(5) extends the tunnel to 
target server 407, as described above. 
Adaptive Encryption and Authentication based on Data 
Sensitivity: FIGS. 6 and 7 

An important task in access control in a VPN is deter- 
mining the minimum amount of security needed by a 
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session. This is important first because at least that minimum 
must be guaranteed and second because more security than 
is necessary wastes resources. The techniques employed in 
access filters 203 to determine the minimum amount are 
collectively termed SEND (Secure Encrypted Network 
Delivery). In SEND, access control database 301 contains a 
data sensitivity level for each information resource. The data 
sensitivity level indicates the level of secrecy associated 
with the information resource and is assigned to the infor- 
mation resource by the security administrator responsible for 
the resource. An exemplary set of levels is Top Secret, 
Secret, Private, and Public. 

The levels used to indicate data sensitivity are also used 
to indicate the trust level required for the access request. As 
previously described, access will be permitted only if the 

5 trust level determined from the trust level of the technique 
used to identify the user, the trust level of the path of the 
access request through VPN 201 or the trust level of any 
encryption technique used to encrypt messages sent over the 
path is at least as great as the data sensitivity level for the 

3 information. The trust levels for user identifications, paths, 
and encryption algorithms are contained in access control 
database 301. With regard to trust levels of paths, the VPN 
is divided into network components, each network compo- 
nent being a connected set of IP networks that is separated 

5 from other components by access filters 203. Each network 
component has a name and a trust level. For example, an 
Internet component will have the Public trust level, while an 
internal network component may have the Private trust 
level. The trust level of a given component may be based on 
its physical security or on the use of encryption hardware in 
the component. As each access filter 203 is added to a VPN, 
a description of its connections to the components of the 
VPN is added to database 301. Included in this description 
are the trust levels of the networks. Consequently, any access 

5 filter 203 can use its copy of database 301 to determine the 
trust level of each component of the path by which a session 
will be carried between a client and a server. 

The trust level for a user is determined from the manner 
in which the access request identifies the user. In access 
control database 301, each group of users has one or more 
identification techniques associated with it, and each iden- 
tification technique has a minimum trust level. The basic 
techniques are: 

5 Certificate via SKIP. A user is identified by the name in his 
or her X.509 certificate used with the SKIP protocol to 
authenticate and encrypt traffic. 
Certificate via User Identification Client. A user is iden- 
tified by the name in his or her X.509 certificate 

3 transmitted to attached access filters 203 via a special - 
Conclave client module called the User Identification 
Client. This transmittal is done securely, using a 
challenge/response mechanism. 
Windows Domain ID via User Identification Client. A 

5 user who logs in to a Microsoft Windows Domain and 
has installed the User Identification Client automati- 
cally has his or her Windows identity, including group 
memberships, transmitted to attached access filters 203. 
The logon to the network is done securely within the 

3 mechanisms of the NetBIOS protocol. 

Authentication Tokens. Authentication tokens (such as 
those manufactured by Security Dynamics Inc. and 
Axent Corp.) may be utilized in two ways: via the User 
Identification Client in an out-of-band manner, or 

5 in-band within the Telnet and FTP protocols. 

IP Address and/or Domain Name. The IP address or fully 
qualified domain name of the user's computer. 
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In a preferred implementation of SEND, the identification 
techniques have a predetermined order from most secure to 
least secure. The techniques just listed would be ordered are 
as they are in the above list, with the most secure techniques 
being at the top of the list. The ordering of the identification 5 
techniques is somewhat subjective, but reflects the general 
security of the identification technique and the rigor applied 
to the distribution and validation of user identities. An 
administrator in VPN 201 then relates the ordered trust 
levels to the ordered identification techniques. For example, 1Q 
if the administrator relates the private trust level to identi- 
fication by means of authentication tokens, a user who 
desires to access a resource with the private sensitivity level 
must identify himself or herself by means of an authentica- 
tion token or another identification technique which is above 
the authentication in the order of identification techniques. 15 
The administrator of the access filter likewise orders the 
cryptographic algorithms available in the VPN from most 
secure to least secure and relates the ordered trust levels to 
the ordered cryptographic algorithms and orders the network 
paths employed in VPN 201 and relates the ordered trust 20 
levels to the ordered network paths. These relationships 
between trust levels and orderings with regard to security are 
included in access control database 301. Then a SEND table 
is constructed which relates trust and sensitivity levels to 
identification and encryption techniques. FIG. 6 is a con- 2 5 
ceptual representation of such a SEND table. 

SEND table 601 has three columns: one, 603 for the 
trust/sensitivity levels, one, 605, for minimum encryption 
methods, and one, 607, for minimum identification methods. 
For details on the encryption methods of column 605, see 3Q 
Bruce Schneier, Applied Cryptography, John Wiley & Sons, 
New York, 1994. Each row 609 of the table associates a 
trust/sensitivity level with a minimum encryption level for 
the path connecting the access filter, client, and server and a 
minimum identification level for the user. Thus, row 609(1) 
associates the "top secret" trust/sensitivity level with the 35 
3DES encryption algorithm and a user certificate obtained 
via SKIP. A user who wishes to gain access to a resource 
with the sensitivity level "top secret" must consequently 
have an identification that is certified by SKIP and if the path 
does not have a "top secret" trust level, the session must be 40 
encrypted with the 3DES algorithm. On the other hand, as 
shown by row 609(4), a user who wishes to gain access to 
a resource with the sensitivity level "public" may be iden- 
tified by any method and there is no requirement that the 
session be encrypted. 45 

When a new session is initiated, the first access filter 203 
in the path employed for the session proceeds as follows: 

1. The access filter determines the information resource 
being accessed and looks up its sensitivity level in 
database 301. 50 

2. The minimum authentication for that sensitivity level 
from SEND table 601 specifies which identification 
mechanisms may be used by the access filter to identify 
and authenticate the user making the access. 

3. The first access filter 203 then consults database 301 to 55 
determine from the user groups the user belongs to and 
the information sets the resource belongs to whether the 
user may access the resource. 

a. The first step is to determine from the access data 
base which of the identification methods used to 60 
identify the user have trust levels high enough for the 
sensitivity level of the resource. 

b. Then first access filter 203 consults database 301 
using the user's identification according to each of 
the identification methods that has a high enough 65 
trust level to determine the user groups that the user 
belongs to. 
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c. First access filter 203 also consults data base 301 to 
determine which information sets the resource 
belongs to. 

d. Having determined the relevant user groups and 
information sets, first access filter 203 consults data 
base 301 to locate the access policies that determine 
whether access is to be allowed or denied to the 
session. If at least one policy allowing access is 
found and none denying access are found, the user is 
allowed access; otherwise, access is denied. Details 
of steps b, c, and d will be given below. 

4. If access was not denied, the first access filter 203 then 
consults database 301 to determine the network com- 
ponents that make up the route through the VPN from 
the client to the server that contains the information 
resource. The route is considered as having up to three 
logical segments: 

a. Segment (a), from the client to the first access filter 
203. This segment may or may not have been 
encrypted, depending upon whether the client uses 
SKIP. 

b. Segment (b), from the first access filter 203 to the 
access filter 203 in the path nearest the server; and 

c. Segment (c), from the access filter 203 nearest the 
server to the server; this segment also may or may 
not be encrypted. 

If segment (a) and segment (c) exist, each will consist 
of a single network component. Segment (a) will not 
exist if the client is on the first access filter; segment (c) 
will not exist if the server is on the access filter nearest 
the server. If segment (b) exists, it will consist of one 
or more network components. Segment (b) will not 
exist if there is only one access filter between the client 
and server. 

5. For each of the segments: 

a. For segment (a), any encryption must be done by the 
client. If the trust level of segmeat(a) is not at least 
as strong as the sensitivity of he resource, or if the 
trust level of the encryption done by the client is not 
at least as strong as the sensitivity of the resource, 
access is denied. 

b. For segment (b), if the weakest trust level of any 
network component in the path is greater than or 
equal to the data sensitivity of the resource, then the 
traffic is sent without encryption. This corresponds to 
the case where the network is inherently secure 
enough to transmit the data. In the example table 
above, information resources with a Public data 
sensitivity level may be transmitted on any network, 
as shown by row 609(4). However, the access filters 
203 will use SKIP to authenticate the session, allow- 
ing subsequent access filters to pass the session 
through without incurring the larger overheads of 
decryption, access checking, and reencryption. If the 
weakest trust level for the path is less than the data 
sensitivity of the resource, then the SEND table is 
consulted for the minimum encryption algorithm 
required for the sensitivity level and the session is 
encrypted using that algorithm. The encryption 
upgrades the security of the link, making it suitable 
to carry data of that given sensitivity and permitting 
access by the user to the resource. 

c. For segment (c), the portion of the path from the 
access filter 203 nearest the server to the server, first 
access filter 203 determines the trust levels of seg- 
ment (c) and of any encryption used in segment (c) 
from information in database 301. If the trust level of 
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this segment of the path is less than the sensitivity meats of access filter 203, the access filter may negotiate the 
level of the information resource, and in that case, if encryption technique to be used in a request with the client 
the encryption used in segment(c) is not at least as in a manner similar to that which it employs in the preferred 
strong as that required as the minimum level in the embodiment to negotiate the user identification mode. 
SEND table considering the sensitivity level of the 5 Overview of the Administrators' Interface to Access Control 
resource, then first access filter 203 will deny access. Database 301: FIGS. 8-12 
The above method of determining sensitivity and trust An access policy defines access in terms of user groups 
levels ensures that access filters 203 employ encryption only and information sets; consequently, before an access policy 
as necessary to achieve the necessary trust levels. This may be defined, the administrators must define the user 
reduces the number of sessions that will be encrypted while 10 groups and information sets; how that is done is shown in 
keeping the description of network configuration in database FIG. 8. Defining a user group involves steps 803 through 
301 simple and manageable. The result is better scalability 807: first the users are defined, then the user groups are 
with regard to both management of and performance in the defined, and then the users are assigned to the proper user 
VPN. groups. Defining information sets involves steps 809 
FIG. 7 provides an example of how the sensitivity level of 15 through 813: first the resources are defined, then the infor- 
an information resource, the trust level of the user matioo sets are defined, and then the resources are assigned 
identification, and the trust level associated with the path to the information sets. When this has been done for the user 
between the client and the server affect access by the user to group and information set involved in a policy, the access 
the information resource. In FIG. 7, a SKIP-equipped user at policy can be created, as shown at 815. As previously 
client 703 initiates a session 701 to obtain an information 20 pointed out, the rights to define and determine the member- 
resource 723 which is stored at SKIP-equipped server 705. ship of user groups and information sets and to make 
Segment (a) of the above discussion appears in FIG. 7 at administrative policy for them are determined by the admin- 
707; segment (b) appears at 709(1 ... 4); Segment (c) istrative policy, while the right to make access policy for 
appears at 711. Information resource 723 has a sensitivity user groups and information sets are determined by the 
level of "secret". The first access filter 203 that the session 25 policy maker policy. 

encounters is filter 203(1). Access filter 203(1) uses its copy As can be seen from the foregoing, the user interface is 

of the access control database to determine the sensitivity generally used to define relationships between two entities 

level of resource 723. Here, the user has used a SKIP or sets thereof. The general form of the graphical user 

certificate and an examination of SEND table 601 in data interface (GUI) for access control database 301 corresponds 

base 301 shows access filter 203(1) that this kind of user 30 to that task. The display includes two windows, each of 

identification meets the requirements for information which contains representations of entities that are to be 

resources having the "secret" sensitivity level, so segment brought into relationship with each other, and the relation- 

(a) 707 has the required trust level. Consequently, the first ship is defined by selecting the entities and where necessary, 
access filter goes on to determine the trust level of segments defining the relationship. 

(b) 709(1 ... 4) and (c) between access filter 203(1) and 35 Defining User Groups: FIG. 9 

server 705 in the VPN. Segment 709 has subsegments FIG. 9 shows the display 901 for populating and defining 

709(1), 709(2), 709(3), 709(4), and 709(5), and first access user groups. Window 903 in the display contains a hierar- 

filter 203(1) checks the trust level of each of these subseg- chical display of currently-defined user groups; window 903 

ments in database 301. Segment 709(2) is Internet 121, so its is similar to those used to display hierarchies of files in the 

trust level is "public", which is the minimum in segment 40 Windows 95 brand operating system manufactured by 

709. Tnen access filter 203(1) uses access control data base Microsoft Corporation. In window 903, user groups for 

301 to check the trust level of segment 711. It is "secret". which the administrative user using display 901 has admin- 

Thus, only segment (b) 709 has a trust level that is too low istrative rights appear in black; the other user groups appear 

for the path of a session that is accessing a "secret" infor- in gray. Above the two windows are two button bars 911 and 

mation resource 703. To deal with this problem, access filter 45 915. Button bar 911 lists the displays available for modify- 

103(1) must encrypt the session to bring it up to the ing access control database 301, while button bar 915 lists 

necessary trust level. First access filter 203(1) consults the operations that may be performed on those displays. 

SEND table 601 to determine what kind of encryption is Thus, the button label "user groups" in button bar 911 is 

required, and row 609(2) indicates that DES encryption is highlighted, indicating that display 901 is the one for popu- 

sufficient. First access filter 203(1) accordingly encrypts the 50 lating and defining user groups. With regard to button bar 

session using that algorithm and sends it to access filter 915, when window 903 is active, an administrative user with 

203(5). the right to administer a user group may modify the user 

In FIG. 7, segment 707 connecting client 703 to access group by selecting it in window 903 and using the delete 

filter 203(1) has a trust level which is high enough for the button in button bar 915 to delete the user group or the new 

resource's sensitivity level, and there is thus no need for 55 button to add and name a new user group that is beneath the 

client 703 to encrypt its request. When that is not the case, selected user group in the hierarchy. When the administra- 

access filter 203(1) will give client 703 access only if client tive user clicks on apply button 921, access filter 203 

703 has encrypted the request using an encryption method modifies its copy of access control database 301 to conform 

whose trust level is sufficient for the sensitivity level of the with what is on display 901 and the modifications are 

resource. It is for this reason that roamer 503 in FIG. 5 must 60 propagated to all copies of access control database 301 in the 

be SKIP-equipped. Since roamer 503 accesses access filter VPN. 

403(3) via Internet 121, roamer 503's requests can never Window 909 displays users. A set of user is indicated in 

have more than the public trust level unless they are the display by the manner in which the user in the set 

encrypted, and in order to have full access to the resources identified. In this case, the users are identified by IP 

in VPN 201, roamer 503 must use an encryption method 65 addresses and they appear in the display as ranges of IP 

such as the one provided by SKIP whose trust level is addresses. Button bar 913 indicates the other kinds of 

sufficient for the highest sensitivity levels. In some embodi- identifications that can be displayed in window 909. As with 
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window 903, when the window is active, the new and delete selected policy definition 1108; access field 1121 permits the 

buttons can be used to add and delete users. To assign the administrator to select either allow or deny as the policy. The 

user(s) specified by a user identification to a user group, the delete button in button bar 1115 permits the administrator to 

user of the GUI selects a user group, as shown at 917, and delete a selected policy; the new button permits the admin- 

a set of identifications, as shown at 919, and then uses the 5 istrator to make a new policy definition 1108; to do this, the 

add to group button in button bar 913 to add the set of administrator selects a user group in window 1103 and an 

identifications to the group, as is shown by the fact that the information set in window 1105 and then pushes the new 

range of IP addresses selected at 919 now appears in the button. The new access policy definition 1108 appears in 

hierarchy below the user group selected at 917. The effect of display 1107, and the administrator can edit the new access 

the operation is to make users whose sessions have the policy definition as just described. To apply a change to 

source IP addresses listed at 917 into members of the user access control database 301 and propagate it to all access 

group R&D, and when the user clicks on the apply button, filters 203, the administrator clicks on apply button 1125. 

all copies of access control database 301 are modified Display 1101 also contains a policy evaluator tool which 

accordingly lets me administrator see how the current set of access policy 

FIG. 10 shows the display 1001 used to define informa- „ definitions determines access for a given user group or 

tion sets. Here, window 1003 contains a hierarchical list of 15 resource *?■ ^ } h * admm^trator clicks on the policy 

information sets and window 1005 contains a hierarchical evaluaUonb unonm button ^^^^ a ™"^> 

r , .. . , ™ ,. u . , ... o from display 1103, the tool displays the selected user group 

list of the available resources. .Jht hierarchical list of m ^ ^ of ^ informatio H n ^ m dis j U 05which 

information sets and the hierarchical list of available user mc H definitions permit the user group to access in 
groups made in the same fashion as the list of user groups. 2Q grcen and the remainder m rcd; all of me policy definitions 
Again, information sets and available resources over which which afe relevant to me determination of which informa- 
the user of display 1001 has administrative authority appear tioQ ^ may be accessed by me ^ group m highlighted 
in black; the other items on the list appear m gray. In window m ^ same set of ^ same thing happens if tne 
1001 the available resources are the Internet and the two administrator selects ^ information set; then the evaluator 
locations that make up VPN 201. In a more developed VPN 25 tQol me selected information set in blue, all of the 
201, the list of available resources would indicate servers at ^ grQups that caQ access ^ inflation m gree n and 
the location, services in the servers, and the information ^ ^ m ^ md ^ highlights the relevant policy 
items provided by the services. For example, if the service definitions. The user can also select a policy. In that case, the 
provides a directory tree, the information items contained in selected po licy appears in blue and the user groups and 
the directory tree would be indicated by means of a path- 3Q mformation ^ affected by the policy in appear in blue or 
name which specified the root of the directory tree and used fedj as determme d by the policy. The user can additionally 
wildcard characters to specify the files above the root in the select mQre thaQ one ^ mformation or p^cy. 
tree. When a resource is added to a server, the resource may In ^ case> ^ evama tor t00 l shows each policy that applies 
be defined via the 1005 window. Havmg thus been defined, tQ all of the selected items me effects of those policies, 
a resource may be assigned to an mformation set m the same 35 ^ evaluator tool can be t^gd off by clicking on policy 
fashion that a user identification is assigned to a user group. evaluation in button bar 1113 and colors and highlights can 
Again, clicking on the apply button causes the changes in be mrned off in prepaxa tion for a new policy evaluation by 
display 1001 to be propagated to all copies of access control clicking on me reS et evaluation button in button bar 1115. 
database 301. p IG 12 shows the display 1201 used to input information 
FIG. 11 shows the display 1101 used to define policies. ^ about ^ access fiUer 20 3 to access control database 301. 
Which type of policy is being defined is specified in button Window ^03 shows a hierarchical list of the access filters 
bar 1113; as indicated there, display 1101 is defining access 203; wnen ^ ^ activC) access mters may be added 
policy. All of the policy displays have the same general 0f ddeted ^ the add and delete buttons in button bar 
format: a window 1103 which contains a hierarchical display ^9 window 120 5 is used to input or display information 
of user groups, a window 1105 which contains a display of 45 about tfae access filter 203 m window 1207 is 
a hierarchy of objects for which policy may be defined and determined by clicking on a button in button bar 1207; as 
a policy definition window 1107 which contains access showD by the buttonS) displays in window 1207 can be used 
policy definitions 1108. In the hierarchy of objects, objects to mput and ^ mformation about acceS s filter 203's 
for which the user of display 1101 has the right to define net work connections, to input and view information about 
policies appear in black; the others appear in gray. In display 5Q the tmst kvels of those connections, to scan networks for 
1101, what is being defined is access policies, so the objects available servers and services, to set up alerts for problems 
are information sets. detected in access filter 203, to specify optional parameter 
Each access policy definition has four parts: for ^awne, and l0 specify the distribution order of access 
an active check box 1117 that indicates whether the access control database 301 changes. The highlighting of alert setup 
policy defined by the definition is active, i.e., being 55 indicates that display 1205 shown in FIG. 12 is the display 
used to control access; used to display and establish alerts, 
the user group 1119 for which the access policy is being User Interface for Discovering Resources: FIGS. 18 and 24 
defined; The users of VPN 201 have an interface for seeing what 
the information set 1123 for which the access policy is resources are available to them in VPN 201. The interface, 
being defined; and 60 termed herein the IntraMap interface (IntraMap is a trade- 
access field 1121, which indicates whether access is being mark of Internet Dynamics, Incorporated), shows each user 
allowed or denied and thereby defines the access policy. at least the resources that belong to the information sets that 
Menu bar 1109 and button bar 1115 permit administrators the user may access according to the access policies for the 
whom the policy maker policy allows to do so to edit, add, user sets the user belongs to. In other embodiments, the 
delete, and activate or deactivate a selected policy definition 65 IntraMap may take the sensitivity level of the resource and 
108. Active check box 1117 of each policy definition 1108 the trust level of the user's identification into account as 
permits the administrator to activate or deactivate the well. 
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The IntraMap interface is implemented by means of a resource descriptions for the resources on it are then 

Java™ applet that runs on any Java-equipped World Wide searched in the order specified in sort field 1809. The search 

Web browser. Using the Web browser, the user can scan the simply looks for whole or partial word matches. It is not case 

graphical display to find and access resources that are sensitive. The first match is displayed, and function keys 

available to the user or to request access to resources that are 5 ma y oe used to navigate to other matches. Of course, if a 

not currently available to the user. Access by a user to a nas not checked a service type in service type field 

resource is determined by the access policies that apply to \g\x, resources of that service type are not involved in either 

the user and the resource. FIG. 18 shows the display 1801 sorting or searching. 

produced by the IntraMap interface. The left-hand side of fig. 24 shows an implementation 2401 of the IntraMap 

IntraMap display 1801 shows a Resource List 1803; the 10 interface. To the user of VPN 201, the IntraMap interface 

right-hand side of the display shows a Find field 1807, a Sort appears as a Web page that is one of the resources provided 

section 1809, a Services section 1811, and a Description by report manager 209 running on access filter 203(c) of 

field 1813. On-line help for using the IntraMap is available FIG. 2. A user in VPN 201 or even the general public (that 

by clicking Help button 1815. someone who is a member of the Internet user group) may 

Resource List 1803 shows resources and information 15 be given access to the IntraMap interface in the same fashion 

available in VPN 201 to the user who is using the IntraMap as he or she may be given access to any other resource. As 

interface. The listing is hierarchical. The user can expand or will be clear from the following description, the Web page 

collapse branches of the "tree" by clicking on the V and f or me IntraMap may be on any server in VPN 201. 

markers on the branches. Each entry 1804 in the list includes Implementation 2401 has components in workstation 2403 

a name for the resource. The color used to display an entry 2 o used by the user to look at the IntraMap, components in 

indicates what kind of access the user has. If the entry 1804 access filter 203(1) which is local to work station 2401, and 

is displayed in blue, the user has an active hyperlink to the m access filter 203(c), which is the access filter upon which 

resource and may double click on the resource to have it report manager 201 runs. Of course, access filter 203(c) may 

displayed. If it is displayed in black, it is also available to the a is 0 function as a local access filter. Local access filter 

user, but no hyperlink is available, so a separate application 2 s 203(0 is connected to report access filter 203(c) by VPN 201 

must be used to retrieve it. Resources displayed in gray are anc j workstation 2403 is connected to local access filter 

not directly available to the user, but if the user selects one, 203(1) by LAN 213. 

the IntraMap interface opens a dialog box that permits the As will be explained in more detail later, all access filters 

user to send email requesting access to the administrator 203 have a layered architecture. The bottommost layer is an 

who is responsible for access policy for the information set 30 Internet packet filter 2419 that deals only with Internet 

the resource belongs to. The administrator may then modify packet headers. Packet filter 219 reads the source and 

the access and/or administrative policies as required to give destination addresses in the Internet packet headers and 

the user access. An administrator may further give a resource applies a set of rules to them. As determined by the rules, it 

the hidden property. When a resource has that property, it e i mer accepts them, discards them, or routes them further in 

will appear in IntraMap interface 1801 only if the user 35 vpn 201. The rules also determine how the accepted 

belongs to a user group that the access policies permit to packets are to be routed within access filter 203. The next 

have access to an information set that the resource belongs i ayer 0 f me architecture is service proxies 2427. The service 

to. If a resource does not have the hidden property, it will proxies intercept traffic for services such as the World Wide 

always appear in IntraMap interface 1801. Otherwise, it Web and do access checking on the traffic. If access filter 

does not appear. A resource may have a more detailed 40 203 provides the service itself or does access checking for a 

description than that contained in its entry 1804. The server that provides the service, IP filter 2419 sends packets 

description is displayed in Description field 1813 when the intended for the service to a service proxy 2427 for the 

user selects the resource. service. The service proxy uses access control database 301 

In addition to resource list 1803, IntraMap display 1801 t0 do protocol-level access checking for the service. For 

displays two specialized resource lists at 1805. 45 example, the service proxy for the Web service may check 

What's New 1806 displays the latest information postings whether the user making a request for a given Web page has 

from others within the enterprise. If an administrator access rights for the page. The next higher level is services 

has given the user access to the What's New web page, level 2425; if the relevant service proxy permits an access 

the user may post the URL of a new resource there. request and the access filter is also the server for the service, 

What's Hot 1808 displays the enterprise's most popular 50 the request goes to the service at service level 2425 to be 

information resources, based on how frequently they processed. In the case of the Web page, the service would 

are accessed. locate the page and return it to the requestor. Two services 

The service types control at 1811 lets the user filter the are involved in the IntraMap: the Web service and an 

resources that are to be displayed in resource list 1803 by the IntraMap service. In FIG. 2401, the Web service appears as 

type of service that provides the resource. Each service type 55 WebS 2423. The proxy for WebS 2423 is WebP 2421; for 

has a check box in service type control 1811. If the box is reasons that will become clear in the following, the IntraMap 

checked, the service type is included and the resources service has only a proxy, IntraMapP 2417. Additionally, 

associated with this service appear in the Resource List. access control database 301 includes IntraMap information 

Otherwise, the resources associated with this service do not 2422, which is an optimized version of the information in 

appear in the Resource List. 60 access control data base 301 that serves as a basis for the 

The IntraMap interface lets the user sort Resource List IntraMap display. 

1803 by information sets, locations, or services. To do this, The chief difference with regard to the IntraMap imple- 

the user selects the way he or she wishes to sort the resource mentation between access filter 203(c) and access filter 

list in sort field 1809. The user may also specify the order in 203(1) is that access filter 203(c) includes a World Wide Web 

which the categories are used in the sort. The interface 65 page 2410 with a copy of IntraMap Java applet 2411. When 

further has a search function. To do a search, the user enters downloaded from access filter 203(1) to Web client 2429 in 

a search string in FIND field 1807. The resource list and the work station 2403, Java applet 2411 produces requests 
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directed to IntraMap server 2425 and uses the results of the logical structure of the database. FIGS. 13-17 are 

returned by IntraMap server 2425 to produce IntraMap displays generated by the Microsoft Jet brand database 

display 1801. system of the schema for access control database 301. FIG. 

Operation is as follows: to the user of work station 2403, 13 shows the schema 1301 for the part of the database that 

the IntraMap may appear as a link to a Web page. Thus, to 5 defines user groups. The display is made up of two elements: 

use the IntraMap, the user activates a link to IntraMap page representations of classes of tables 1303 in the database and 

2410. Web browser 2429 in workstation 2403 responds to representations of links 1305, which show relationships 

the activation of the link as it would to the activation of any between tables belonging to certain classes of tables. The 

other link to a Web page: it makes a request for the page and representation of the class of the table shows the name of the 

sends it to the server indicated in the link. In the case of the 10 class at 1310 and the data fields that will be contained in 

link to the IntraMap, the link specifies Web server 2423 in each table belonging to the class at 1308. Each table instance 

access filter 203(c), so the request goes via local access filter has an ID assigned by the database system. The other data 

203(1) and VPN 201 to access filter 203(c). As with any in the table varies with the class of table. A link is made 

other access to a resource in VP 201, local access filter between a first table belonging to the first class of tables and 

203(1) does access checking for the IntraMap page request. 15 a second table belonging to the second class of tables by 

Since the request is for a Web page, the checking is done by using the ID of the second table in the first table and 

Web proxy 2421. In most VPNs 201, IntraMap page 2410 vice-versa. Thus, link 1305 shows that tables of the class 

will be accessible to any user in VPN 201, and access control User Group Tree table 1307 can be linked with tables of the 

data base 301 thus indicates that any user with a valid IP class User Groups table 1309. Some links have numbers at 

source address may access IntraMap page 2410. 20 their ends. The numbers indicate the number of the links that 

When the request is received in access filter 203(c), IP the table at the end the number is located at may have. Thus, 

filter 2419 forwards it to Web proxy 2421, which in turn the link connecting the table of class 1309 and the table of 

forwards it to Web server 2423, which responds to the class 1307 has the number 1 at the end for the table of class 

request by downloading IntraMap applet 2411 to Web 1309 and the number oo at the end for the table of class 1307, 

browser 2429 in work station 2403, where IntraMap applet 25 indicating that any number of IDs of instances of class 1309 

2411 begins executing in Web browser 2429. During may appear in an instance of class 1307, but only one ID of 

execution, it sends a request to IntraMap proxy 2427 for an instance of class 1307 may appear in an instance of class 

IntraMap information 2422. like all Java applets, IntraMap 1309. 

applet 2411 sends the request to the server that it is resident User Group Tables: FIG. 13 

on, in this case, access filter 203(c). However, as with any 30 User group tables 1301 contains a table of class user 
other request from workstation 2403, the request goes by groups 1309 for each user group in database 301. Data of 
way of local access filter 203(1). There, IntraMap proxy particular interest in tables of class User Groups 1309 
2427 detects that the request is addressed to IntraMap proxy include the group name, which is the character-string name 
2427 in access filter 203(c) and instead of sending the of the group, the group description, which is a character- 
request on to access filter 203(c), obtains IntraMap infer- 35 string description of the group, and pre-defined information, 
mation 2422 from the local copy of access control data base which indicates among other things whether a user who is a 
301 in local access filter 203(1), filters it so that it specifies member of the group is an administrator, i.e., can make 
only those resources belonging to the information sets to administrative policy, a security officer, i.e., can make policy 
which the user groups to which the user belongs have access maker policy, or a simple user of information. User group 
to make to list 2431 and returns it via LAN 213 to IntraMap 40 tables 1301 further organizes the user groups into a 
applet 2411, which then uses list 2431 to make IntraMap hierarchy — both for the purposes of inheritance and also for 
display 1801. In making the display, applet 2411 applies any the hierarchical display of user groups shown in window 903 
filters specified in the request and also sorts the list as of FIG. 9, associate identifications of users with the user 
specified in the request. list 2431 not only indicates the groups, and associate alerts with the user groups. The 
resources that are available, but also contains information 45 organization into the hierarchy list is done by means of 
needed to fetch the resource. Thus, if the resource has a tables of class User Group Tree 1307. Each table of the class 
hyperlink, the hyperlink is included in the list; if it is a User Group Tree links a table of the class User Group to a 
resource for which the user presently does not have access, parent user group (also of the type User Group). Multiple 
but to which the user may request access, the list includes the User Group Tree tables may exist for a particular User 
name and email address of the administrator for the 50 Group table, depending on the number of places in which a 
resource. particular user group appears. 

Details of Access Control Database 301: FIGS: 13-17 As already mentioned, there are five different ways of 

In a preferred embodiment of access filter 203, access identifying users to an access filter 203: by a range of IP 

control database 301 is implemented at two levels: one used addresses, by a fully-qualified Internet domain name, by the 

by the graphical user interfaces use to manipulate access 55 identity of the user in the Microsoft Windows brand oper- 

control database 301 and another used in actual access ating system, by an authentication token, and by certificate, 

checking. The first level is implemented using the Microsoft The table classes for the tables used to identify users by 

Jet brand database system developed by Microsoft Corpo- certificates are shown as 1321. The table classes for the 

ration. The second is implemented using memory mapped tables that identify users by a range of IP addresses are 

files (MMFs) which are compiled from the first-level data 60 shown at 1317; those for the tables that identify users by IP 

base. The following discussion will describe the first-level domains are shown at 1319; those for the tables that identify 

implementation and explain how the information contained users by Windows brand operating system ID's are shown at 

in it is used in access checking. In reading this discussion, 1315; and those for the tables that identify users by authen- 

it should be remembered that actual access checking is done tication tokens (labeled as smart card in the figure) are 

using the MMF.s, as will be described in detail later. 65 shown at 1323. The table classes 1325, finally, define tables 

As is the case with most database systems, the Microsoft for the information used in alerts that are related to user 

Jet brand database system has a schema, that is, a description groups. A table of User Group class 1309 may have asso- 
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ciated with it any number of tables for any of the ways of 
identifying users. As this implies, a given user may be 
identified in a number of different ways at once. 

In order to perform an access check, access filter 203 must 
determine what user groups the user making the request 5 
belongs to. The request includes an identification for the 
user, and the identification is the starting point for the 
determination. The tables in user group tables 1301 permit 
access filter 203 to determine from the identification what 
user groups the user belongs to and from those user groups, 10 
the hierarchical relations that determine the other user 
groups the user belongs to. Assuming that the user is 
identified by an IP address, access filter 203 begins by 
finding one or more tables of the IP Range Definition class 
(in 1317) which define ranges of IP addresses which include 15 
the user's IP address. Each of these tables has a link to a 
table of the IP Ranges class (in 1317) which relates the range 
defined in the IP Range Definition class table to a user group 
ID, which in turn serves as a link to a table of class User 
Groups 1309 for the user group corresponding to the range 20 
of IP addresses. Each of the tables of class User Group has 
a link to a table of class User Group Trees, from which links 
can be followed to the tables of class User Groups for the 
user groups from which the user groups specified by the IP 
addresses inherit access rights. Thus, at the end of the 25 
process, IP filter 203 has located all of the user groups which 
are relevant for determining whether the user may access the 
resource. Moreover, IP filter 203 knows from the request 
how the user is identified and can determine from that what 
level should be assigned to the identification of the user used 30 
in the request. The information in user group tables 1301 is 
compiled into MMFs. When a user initiates a session, the 
user provides a user identification to the first access filter 203 
on the session's path; access filter 203 uses the user iden- 
tification with the MMFs to make a determination equivalent 35 
to the one explained above. Access filter 203 can thus 
determine for a given user identification whether it identifies 
a user that has access, what kind of user identification it is, 
and therefore what trust level it has, and which user groups 
the user belongs to. User group tables 1301 thus contain all 40 
of the information needed for the user portion of an access 
policy 1108. 

Information Set Tables: FIG. 14 

FIG. 14 shows the schema 1401 for the tables that define 
information sets. These tables relate information sets 45 
(resource groups in FIG. 14) to the resources that make them 
up and to the network locations of the resources and also 
organize the information sets into the hierarchical list of 
information sets displayed at 1003 of FIG. 10. Each infor- 
mation set in access control database 301 is represented by 50 
a table of class resource group 1403. Tables of class resource 
group are organized into a hierarchy for inheritance and 
display purposes by tables 1419. The relationship between 
an information set and the resources that make it up on one 
hand and the locations in the VPN in which they are stored 55 
are established by tables of class resource group elements 
1407. A table of class resource group may be linked to any 
number of tables of class resource group elements. A table 
of class resource group elements is linked to any number of 
tables of the classes Site Elements 1411, Services 1413, and 60 
Resources 1409. 

There is a table of class Resources for every resource 
represented in database 301. Included in the table are the 
resource's ID, its name, the ID for the service that provides 
it, an ID for a definition of the resource's sensitivity level, 65 
a description of the resource, the email address of the 
administrator of the resource and a hidden flag which 
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indicates whether IntraMap should display the resource to 
users who do not belong to user groups that have access to 
the resource. The IntraMap interface obtains the information 
it needs about a resource from the Resources table for the 
resource. 

The tables of the classes Site Elements and Services, as 
well as those of the classes Sites 1415 and Servers 1417 
belong to the classes 1421 that describe the locations of 
information in the VPN. There is a table of class Sites for 
every physical location in the VPN; there is a table of class 
Servers for every server in the VPN; and there is a table of 
class Services for every service in the VPN. Links in the 
tables of class Site Elements relate sites to servers; links in 
the tables of class Servers relate the servers to the services 
they offer, and links in the tables of class Services relate the 
services to the resources that they host. 

In determining what information sets a requested resource 
belongs to, access filter 203 begins with the information in 
the request. The request is contained in an IP packet, and 
consequently has a header and a body. In the header there is 
an IP address which specifies a location in virtual network 
201 and a server at the location, a port number which 
specifies a service on the server, and in the body, the 
description of the resource in the form prescribed by the 
protocol. For example, if the request is for a Web page, the 
description of the resource will be the resource's URL. 
Access filter 203 uses the IP address to locate a table of class 
Sites, uses the link in that table to locate a table of class Site 
Elements 1411. That table relates the site to the server IDS 
for the servers at the site and access filter 203 uses the server 
IDS to locate the tables of class Servers 1417 for the site's 
servers. It can then use the IP address again to locate the 
table of class Servers corresponding to the server specified 
in the request and can follow the links from the Server table 
to the tables of class Services for the service and can use the 
port number from the request to find the proper Service 
table. Once it has found the proper Service table, it can 
follow the links to the tables of class Resources 1409 and 
locate the Resources table corresponding to the resource in 
the request. From there, there is a link to a table of class 
Resource Group Elements 1407 which relates resources to 
the resource group identifiers for the information sets they 
belong to. The resource group identifiers in turn specify 
tables of class Resources Group 1403, and these tables have 
links to tables of class Resource group Tree, from which the 
hierarchies of resource groups can be determined to which 
the resource specified in the request belongs. Having done 
that, access filter 203 has found the resource groups that are 
relevant for determining whether the request should be 
granted. Resources table for the resource further contains the 
sensitivity level for the resource. Again, the information in 
information set tables 1401 is compiled into MMFs. When 
the request reaches the first access filter 203 in the path 
between the user and the server that provides the resource, 
the first access filter 203 uses the MMF files to make a 
determination that is the logical equivalent of the one just 
described. Thus, alter examining the MMF files that contain 
the information from User Groups tables 1301 and Infor- 
mation Sets Tables 1401, the proxy has determined the trust 
level of the user identification, the sensitivity level of the 
information resource, the user groups the user belongs to, 
and the information sets the information resource belongs to. 
Policy Tables: FIG. 16 
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FIG. 16 shows the tables used in access control database 
301 to define access control policies; included in these 
policies are access policies, administrative policies, and 
policy maker policies: 

Access policies relate user groups to resource groups; 

Administrative policies relates a user group whose mem- 
bers are administrators to one of: 



d. 


another user group 


c. 


an information set 


t 


a resource 


fi- 


a location (site) in the VPN 


ll. 


an access filter 203 oi other server 


i. 


a service 



Policy maker policies relate user groups of administrators 
to information sets. Each policy relates a left-hand side, 
which is always a table of class User Groups 1309, to 
a right-hand side, which, depending on the kind of 
policy, may be a table of class Resources 1409, a table 
of class Resource Groups 1403 (representing informa- 
tion sets), a table of class Sites 1415, a table of class 
Services 1413, a table of class Servers 1417, or a table 
of class User Groups 1309. Policy tables 1601 thus fall 
into three large groups: left-hand tables 1603, policy 
tables 1605, and right-hand tables 1609. The right to 
change policies is hierarchical: a member of a user 
group whose User Group table indicates that it is a 
group of a type of Administrators can change access 
policies as determined by the administrative policy for 
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15 



20 



25 
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the group. In turn, those administrators may specify 
other administrative policies related to their sub- 
domain. 

Corresponding to the three kinds of policies, there are 
three classes of tables in policy tables 1605: tables belonging 
to Policies Access class 1611, Policies Administer class 
1613, and Policies Policy Maker class 1619. Tables of all of 
these classes share a number of features: they contain the ID 
of the user group table for the left-hand side of the policy, 
the ID for the table representing the item specified in the 
right-hand side of the policy, an indication of the policy 
(access allowed or denied), an indication of whether the 
policy is pre-defined and cannot be deleted, and an indica- 
tion of whether the policy is presently active. The difference 
between the classes is what can be on the right-hand side of 
the policy, and therefore the links to the entities on the 
right-hand side; in the case of access policies and policy 
maker policies the right-hand entities are information sets 
only, and consequently, tables of the Policies Access and 
Policies Policy Maker classes contain right-hand links only 
to tables of the Resource Groups class, while tables of the 
Policies Administer class may contain right-hand links to in 
the alternative tables of class User Groups, tables of class 
Resource Groups, tables of class Sites, tables of class 
Servers, tables of class Services, and tables of class 
Resources. The rights given the user group specified by the 
user group on the left-hand side of an administrative policy 
over the sets of entities specified by the right-hand side vary 
depending on the kind of entity, as shown in the following 
table: 



Left- Right- 
hand hand 

Side Side Meaning of "allowed" Access 



User group any Members of the user group can create administrative policies for the 

target or included items. This allows for the delegation of 
responsibilities. 

User group User group Members of the user group can administer the target user group, 

including nested user groups. Allowed administration includes deleting, 
moving, and copying the target user group; nesting it in another user 
group; adding members to it; and nesting other user groups in it. 

User group Information Members of the user group can administer the information set, including 
set nested information sets. Allowed administration includes deleting, 

moving, and copying the target information set; nesting it in another 
information set; adding members to it; and nesting other information sets 
in it 

User group Site Members of the user group can administer the site, including elements 

under it from the Available Resources list (all Access Filters, servers, 
services, and resources). Allowed administration includes deleting and 
moving the site; adding it to an information set; and adding locations and 
Access Filters to iL Control over the Intranet location is necessary in 
order to define new Access Filters. 

User group Access Filter Members of the user group can administer the Access Filter, including 
elements under it from the Available Resources list (all servers, services 
and resources). Allowed administration includes deleting and moving 
the access filter; adding it to an information set; and adding servers or 
services to it 

User group Server Members of the user group can administer the server, including elements 

under it from the Available Resources list (all services and resources). 
Allowed administration includes deleting and moving the server, adding 
it to an information set; and adding servers or services to iL 

User group Service Members of the user group can administer the service, including 
resources under it from the Available Resources list (all resources). 
Allowed administration includes deleting, moving, and copying the 
server; adding it to an information set; adding resources to it 

User group Resource Members of the user group can administer the resource. Allowed 

administration includes deleting, moving and copying the resource and 
adding it to an information set 
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The following table describes the rights given adminis- X.509 certificate for the access filter used by SKIP. The 
trative user groups when they appear on the left-hand side of X.509 certificate also includes a public key for access filter 
a policy maker policy: 203. The public key may belong to one of a number of name 



Left- 






hand 


Right-hand 




Side 


Side 


Meaning of "allowed" Access 


User group 


Infonnation 


Members of the user group can manage access policies controlling 


set 


access by any user group to the information set, including nested 






information sets. They may also include the information set and any of 






its descendants in a further policy maker policy. 



As pointed out in the discussion of the Information Set 
tables above, the proxy that is doing the access checking can 
use the User Group tables and the Information Sets tables to 
find the user groups the user making the access request 
belongs to and the information sets the information resource 2 o 
being accessed belongs to and can also use these tables to 
determine the trust level of the user identification and the 
sensitivity level of the information resource. The proxy can 
thereupon use the Policies Access tables to find whether any 
of the user groups the user belongs to may access any of the 25 
information sets the information resource belongs to. If any 
such user group is found, the user may access the informa- 
tion set if the request's trust level is as high as the infor- 
mation resource's sensitivity level. To determine the 
request's trust level, the proxy must determine the trust level 30 
of any encryption technique being used and/or the trust level 
of the path in VPN 201 that is being used for the access. This 
information is available in access filters tables 1701, shown 
in FIG. 17 and described below. If either the access policies 
or the access request's sensitivity level do not permit the 35 
access, the message is disregarded and any session it belongs 
to is dropped. The access checking process is substantially 
the same when the request is a request by a user who is a 
member of an administrative user group to access database 
301, except that when access is permitted, it may result in a ^ 
modification of the database in accordance with the rules set 
forth above. That modification will then be propagated to all 
other access filters 203 in VPN 201. 
Server Tables: FIG. 17 

FIG. 17 shows the schema for tables that are particularly 45 
significant for the operation of servers in the VPN. There are 
three kinds of servers in the VPN: 

Plain servers. These are the servers upon which the 
resources are stored and which execute the services by 
means of which the resources are accessed. 50 

Access filters 203. 

Policy manager servers. These are access filters 203 that 
additionally coordinate and distribute database 301 
and/or generate reports about operation and status of 
the VPN. 55 

An access filter 203 may function additionally as a plain 
server. 

There is a table of class Servers 1417 for every server in 
the VPN. Information in the table for each server included 
its ID, name, domain in the Windows NT brand operating 60 
system, its Internet name, whether it is an access filter 203 
and additionally a policy server, whether access to it is 
available only via an access filter 203, and whether it is 
inside the VPN. If the server is an access filter 203, it 
additionally has an identity that access filter 203 provides to 65 
other entities in VPN 201 for purposes of authentication and 
encryption. In a preferred embodiment, the identity is the 



spaces; the NSID (name space ID) is an identifier for the 
public key's name space; the MKID (master key ID) iden- 
tifies the public key within the name space. Also included in 
the table is a link to a table of class Certificate Authority 
1711 that indicates the certificate authority that issued the 
X.509 certificate for the access filter. Of course, servers 
other than access filters may also have X.509 certificates, 
and in that case, their Server tables will have the server's 
NSID and MKID. 

Every plain server in the VPN has one or more services 
running on it. For example, an FTP service provides access 
to files (the resources) on the server according to the file 
transfer protocol of the TCP/IP protocol suite. Each table of 
class Servers 1417 for plain servers has links to a group of 
tables that define the services and resources available on the 
server. As shown at 1719, these tables include tables of class 
Services 1413, which represent the services, tables of class 
Resources 1409, which represent the resources available via 
the services, and tables of class Service Definitions 1715 
which define the service. 

The remainder of the tables for which FIG. 17 gives the 
schemas contain information that is used by access filters 
203. The tables whose classes are shown at 1705 contain 
information used by access filters 203 th at are policy 
managers to distribute database 301 and/or to generate 
reports; the tables whose classes are shown at 1717 contain 
information about optional parameters for the software 
being run by a given access filter 203; those whose classes 
are shown at 1709 contain information about the proxies and 
other software modules that access filters 203 use to do 
protocol-level access checking in access filter 203; and the 
tables at 1707 contain infonnation about trust and sensitivity 
definitions for identifications of users and kinds of encryp- 
tion. 

The tables indicated by the reference number 1708 con- 
tain information about the VPN to which access filter 203 
belongs. Access filter 203 uses this information to route 
sessions and also to determine the trust level of the path 
being used for a given session. Routing table class 1721 
defines tables that list the current routes to all networks 
accessible from access filter 203. It is automatically updated 
as those routes change. Attached Network class 1723 defines 
tables that indicate for each access filter 203 the networks 
that access filter 203 is presently attached to; tables of that 
class contain links to tables of class Network Definition, 
which in turn contain a link to a definition in trust definitions 
1707 which indicates the trust level of the network. The last 
class in this group is Point to Point Connection 1713, which 
defines tables that describe connections between access 
fillers 203 accessible via the VPN. There is a table for each 
combination of source and destination access filter 203 and 
a link to a trust definition that specifies the trust level of the 
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path between the source and destination access filters 203. 
The trust level in this table is based on the encryption 
technique used for messages traversing the path. 

As previously explained, the User Group tables 1301 and 
the In formation Sets tables 1401 provide the information 5 
needed by access filter 203 to determine whether the access 
policies of tables 1601 permit the access and also provide 
information about the sensitivity level of the resource being 
accessed. Access filters tables 1701 additionally provide the 
information needed by access filter 203 to determine the 10 
minimum trust level of the path in the VPN being taken by 
the session and the trust levels of the available encryption 
algorithms. Thus, if access filter 203 determines that a given 
user wishing to access a given resource belongs to a user 
group which has the right to access the information set to 15 
which the given resource belongs and that the authentication 
level used for the user's identification is no lower than that 
required for the resource's sensitivity level, access filter 203 
can further determine whether the trust level of the path is 
sufficiently high, and if it is not, access filter 203 can raise 20 
the trust level the necessary amount by selecting an encryp- 
tion algorithm with the required trust level and encrypting 
the session. 

Available Information Tables: FIG. 15 

FIG. 15 shows the schema for available information 25 
tables 1501. The tables are used by filter 203 to produce 
available resources display 1005, shown in FIG. 10. The 
table classes shown at 1502 relate each server to its services 
and to the resources provided by the services. The table 
classes shown at 1504 organizes the available resources into 30 
a hierarchy for inheritance purposes and are also used to 
produce the hierarchical list shown at 1005, and by follow- 
ing the links from the Site Elements tables, to the Servers 
tables, access filter 203 can determine the hierarchy of sites, 
servers, services, and resources. The table classes at 1503, 35 
finally, establish a distribution tree of access filters 203. As 
will be explained in more detail later, when access control 
database 301 is modified, the tree defined by those tables 
determines the order in which modifications are distributed 
to the access filters. 40 
Modifying Access Control Database 301: FIG. 19 

As previously mentioned, each access filter 203 has an 
exact duplicate of the copy of access control database 301 
belonging to master policy manager 205 in access filter 
203(a) of FIG. 2. FIG. 19 shows how that copy of access 45 
control database 301 is modified and how the modifications 
are distributed from access filter 203(a) to the other access 
filters 203. 

FIG. 19 shows access filter 203(a) with master policy 
manager 205 and another access filter 203(0 at which an 50 
administrator using a workstation is modifying access con- 
trol database 301. The messages 1909 needed to distribute 
and synchronize the modifications are encrypted using SKIP 
and sent via VPN 201 using a protocol called the private 
communications service (PCS). Each of the access filters has 55 
a number of copies of access control database 301. Any 
access filter 203 has at a minimum two copies: live database 
(LDB) 1907, which is the database currently being used to 
do access checking, and mirror database (MDB) 1905, 
which is a copy of the database that can be switched in to be 60 
used in place of live database 1907. Thus, access filter 
203(a) has an MDB 1905(a) and an LDB 1907(a) and access 
filter 203(0 has MDB 1905(0 and LDB 1907(i). 

If an access filter 203 is being used by an administrator to 
modify access control database 301, then it will additionally 65 
have at least one working database (WDB) 1903. The 
working database is a copy of the database that is not being 
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used to control access and therefore can be modified by the 
administrator. The administrator does so using a workstation 
or PC connected via a network to the access filter. The 
workstation or PC displays the administrative graphical user 
interface described above, and the administrator uses the 
GUI to make the changes as enabled by administrative 
policies. The changes may affect any aspect of the informa- 
tion stored in access control database 301. As indicated 
above, where the changes are changes in access or admin- 
istrative policies, the administrator can use the policy evalu- 
ation feature to see the effect of the changes. When the 
administrator is satisfied with the changes, he or she clicks 
on the apply button and the changes are distributed to all of 
the access filters and incorporated into each access filter's 
live database. 

The process of updating all of the live databases is called 
database synchronization and distribution. The process has 
three phases: 

First, the modifications are sent from the access filter 203 
where they were made (here, access filter 203(0) t0 
access filter 203 to which the master database belongs 
(here, access filter 203(a)). 
There, the changes are incorporated into the master data- 
base. This is done by incorporating the changes into 
mirror database 1905(a), then swapping live database 
1907(a) and mirror database 1905(a), and then chang- 
ing the new mirror database 1905(a). 
Then, the changes are distributed from the Master Policy 

Manager to other Access Filters. 
At each access filter 203, synchronization is done in the 
same fashion as with access filter 203(a). The order in which 
the changes are made in the access filters 203 of VPN 201 
is determined by distribution tree 1511, which in turn is set 
up using filters display 1201. The access filter 203 with 
master policy manager 205 is always the root of the tree. By 
default, the first access filter 203 installed in VPN 201 has 
master policy manager 205. As other access filters 203 are 
installed, they are added to the tree as children of the Master 
Policy Manager. 

The Master Policy Manager distributes changes to its 
children sequentially. As each child access filter 203 receives 
its distribution, it then distributes to its children. This means 
that a shallow distribution tree with many branches off the 
top level will complete a distribution cycle faster than a deep 
distribution tree with few branches off the top level. An 
administrator with the proper access can reconfigure the 
distribution tree to make distribution more efficient. 

If two administrators have modified the same piece of 
information (for example, an access filter definition) in 
different working data base 1903, a synchronization conflict 
can occur. When this happens, master policy manager 205 
decides which modification to incorporate into access con- 
trol database 301. 

Optimizing Access Control Database 301: FIGS. 21 and 23 
Although appropriate for persistent storage and use by 
administration GUI 1915, database 301 is not optimized for 
use in real-time access checking. As will be explained in 
more detail below, access filter 203 optimizes the data in 
database 301 that is required for run-time access checking 
and to make the display for the IntraMap. It does the 
optimization each time a new copy of database 301 is 
received in access filter 203. In its optimized form, database 
301 is a set of Memory Mapped Files (MMFs) in which the 
access policy information is stored in a form which permits 
quick access. The MMFs are so called because they are 
generated as normal files, but then attached to a program's 
memory space and accessed by means of memory operations 
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instead of file operations. A further optimization is achieved run as applications programs at user level 2003 of the 

by using the MMF files to generate rules that are used to do operating system and those that run at the kernel level 2005 

low-level filtering of messages by IP source and destination of the operating system. In general, the programs that run at 

addresses and port numbers for which access is allowed or the kernel level do IP-level access checking and encryption 
( j eme< j 5 and authentication, while those that run at the user level do 

FIG.' 21 shows an example MMF file 2303. The MMF file application-level access checking. Also included in the user- 

in question is DBCertificatesbyUserGroupFile 2101, which level components are software that ravages access control 

maps the certificate matching criteria used to identify cer- wftwa f e £ at P/ 0 *"* 8 me MMFs and 

•c . *i_*ui . i _~ _~ ♦ -j „ * rules for IP-level access checking from access control data- 

tificates that belong to particular user groups to identifiers in . ™ m. * n a- • n u ■ -*u «u 
- , c j c it a j u .u base 301. The following discussion will begin with the 

database 301 of records for the user groups specified by the 10 kerael compon e nt s, continue with the user-level components 
certificate matching catena File 2101 thus permits a proxy re , ated tQ access database 301 and ^ ^ deal 

that has the certificate that identifies the source of a message ^ the for prot ocol-level access checking, 

that has been encrypted using SKIP to quickly determine the Kernel-Level Components 

user groups that the user identified by the certificate belongs Network Interface Cards (NICs) 2013: These are the 
to. In the preferred embodiment, the certificate matching 15 ethernet and token ring cards installed in access filter 203. 
criteria are the O, OU, and CA fields of the X.509 certificate. Three network cards are typically configured. One is con- 
All MMF files 2303 have the same general form: there are figured for the interface to the Internet, to a wide area 
two main parts: a header 2103 which contains the informa- network (WAN) 2011, or to a network connected to another 
tion being mapped from and a data part 2105 which contains access filter 203. Another is configured for interface 2007 to 
the information being mapped to. Header 2103 contains a 20 all client computers and a third is configured for interface 
list of entries 2107. Each entry contains a value being 2009 to the servers providing TCP/IP services. If there is no 
mapped from (in this case certificate matching criteria need for an access filter 203 to be interposed between clients 
(CMC) 2109) and a pointer 2111 to a record in data 2105 and servers, there may be only two NICs 2013, one to WAN 
which contains the information being mapped to (in this 2011 and the other to a LAN. There will be no need for the 
case, a list 2115 of identifiers 2113 in database 301 for the 25 access filter t0 be interposed if no servers exist at access 
user groups that the user identified by CMC 2109 belongs filter 203 ' s location or if it is acceptable for all local clients 
to). The entries in header 2103 are sorted by the information 10 have access to a11 local information resources, 
being mapped from (here, CMC 2109), so that standard fast SHIM 2017: at installation time, a shim software module 
searching algorithms can be used to locate an entry 2107 ^ inserted between two levels of the Windows NT brand 
corresponding to a given set of certificate matching criteria. 30 operating system (the NDIS and TDIS levels). This causes 
FIGS. 23A, B, and C provide a complete list of the MMF *U traffic for particular protocols to pass through SHIM 
files 2301 that are employed in one implementation of 2017. In the implementation, all traffic for TCP/IP protocols 
access filter 203. The relationship between these files and the pass through SHIM 2017, while non-TCP/IP protocol traffic 
tables of database 301 will be apparent from the descriptions g^s directly from the NIC to the appropriate other kernel 
of the contents of the files provided in the table. Each MMF 35 modules. SHIM 2017 invokes SKIP module 2021 as 
file 2303 is represented by an entry in the table which required to process the TFCP/IP protocol traffic, 
indicates the file's name and its contents. The files are SKIP module 2021: Ml IP network traffic is sent through 
subdivided into groups 2311, 2313, 2319, 2321, 2323, and SKIP module 2021. If an incoming packet is not SKIP type, 
2422. Files of particular interest are DBUsersFile 2307 and i does not require the authentication and decryption 
DBResourcesFile 2309, which describe policies, DBCertifi- 40 services performed by SKIP, then SKIP module 2021 passes 
catesByUserGroupFile 2101, which is the MMF file shown il to IP filter module 2019. Similarly, if an outgoing packet 
in detail in FIG. 21, DBResourcelDbyServicelDFile 2315, is not t0 °e encrypted, then SKIP module 2021 sends it 
which relates URLs of resources to resource IDS, DBRe- directly to the proper NIC 2013 for transmission. With 
sourcesbyResourcelDFile 2317, which relates resources to SKIP-type packets, authenticator 2024 in SKIP module 2021 
resource groups, and DBTrustTableFile 2325, which imple- 45 serves to authenticate a session and encryptor/decryptor 
ments SEND table 601. Moreover, the following files are 2022 serves to encrypt and decrypt information at a session 
used to compile rules: level. Both authentication and encryption/decryption may be 

done with an arbitrary number of other access filters 203, 
servers that employ SKIP, and clients that employ SKIP. 

50 Authentication and encryption algorithms are set by IP filter 

DBServcriDByNameFile module 2019 for outgoing packets based on SEND param- 

dSSXS « jpedfied wito incoming packets. 

DBAttachedxNetworisBySeivcrlDHlc SKIP module 2021 maintains enough state information 

DBRoutingTiibleFile for each other site that it talks to so that it can maintain 

DBRoutingTabiebyScivcriDFae $$ high-speed operation for most SKIP-type packets. Packets 

are sometimes 'parked 1 while additional processing (shared 
The files in IntraMap information 2422, finally, are filtered secret and temporary key calculation) is performed, 'skipd' 
to make list 2431, which is then downloaded to the client for module 2037 in user space 2003 performs this extra pro- 
use by IntraMap applet 2411. cessing. 

Details of Access Filter 203: FIG. 20 60 IP Filte r 2019: The IP filter operates on a set of rules that 

FIG. 20 is a block diagram of the architecture 2001 of an toe rules compiler, a component of database service 2029, 
access filter 203. In the implementation shown in FIG. 20, makes from the access policies in access control database 
all of the components of access filter 203 other than NIC 301. The basic functions of IP filter 2019 are to: 
cards 2013 are implemented in software. The software of the a. Pass traffic up to the TCP/IP stack, 
implementation runs under the Windows NT brand operat- 65 b. Block traffic — explicitly drop traffic for specific IP 
ing system manufactured by Microsoft Corporation. The addresses and according to special rules for emergency 

software components fall into two broad classes: those that conditions. 



09/13/2004, EAST version: 1.4.1 



6,K 

39 

c. Drop traffic — implicitly drop traffic that neither 
matches any rules nor is allowed by any policies. 

d. Proxy traffic — rather than deliver traffic to the indicated 
destination, route it to a proxy application on the 
current machine. 

e. Perform network address translation — change poten- 
tially illegal internal IP addresses to legal ones. 

f. Pass decisions off to pr_ipf (discussed below) upon 
establishing a new session for which access control 
cannot be decided strictly by the rules. Typically, this is 
for sessions that may be allowed by policies or by the 
VPN tunneling features described previously. 

IP filter 2019 performs these functions based on the 
following information: 

Rules generated by the rule compiler; 
Source and destination IP address and port; 
Encryption, or lack of it, on the incoming packet; and 
Desired encryption and authentication on outgoing pack- 
ets. 

Components having to do with Database 301 

Shared Directory 2028: VPN 201 uses a single access 
control database 301 that is kept resident in each and every 
access filter 203. All versions of database 301 in a given 
access filter 203 are maintained in shared directory 2028. 
Shared directory 2028 also contains each access filter 203' s 
log files. 

Private Connect Service (PCS) Module 2025: PCS mod- 
ule 2025 provides access filter-to-access filter communica- 
tions in VPN 201. All such communications go through the 
PCS. The PCS has its own IP port number and its messages 
must be encrypted. The particular functions carried out by 
means of PCS messages are: 

Distribution tree management; 

Distribution and synchronization of database 301; 

Retrieval and distribution of routing table 1721; 

Retrieval of Windows domain and user information; 

Network scanning; 

Retrieval of log contents; and 

Transfer of files used by reporting and other subsystems. 

ISDB Manager 2027: ISDB manager 207 manages data- 
base 301. It and the PCS are the only interfaces to the copies 
of database 301 in each access filter 203. It contains the 
software used to read and write all tables in the copies of 
database 301. 

DB Service and Rules Compiler 2029: DB Service 2029 
produces MMF files 2301. It does so each time a new copy 
of database 301 is received in access filter 203. It utilizes the 
functions provided by ISDB Manager 2027 to read live 
database 1907(1) for a given access filter 203(1) and generate 
the MMFs 2301. A component of DB service 2029 is the 
Rule Compiler, which generates rules for use in the IP filter 
module from relevant ones of the MMFs 2301. The rules 
specify IP sources, destinations, and port numbers for which 
access is allowed or denied. The Rule Compiler exists as 
both a DLL and an application program that simply invokes 
routines in the DLL. In normal operation, the routines in the 
DLL are invoked by the DB Service whenever a modified 
database 301 is received in access filter 203(1) from master 
policy manager 205. The application program is used in 
special modes during the installation and bootstrapping 
process. 

Memory Mapped Files (MMFs) 2301: As already 
explained, the MMFs 2301 are data files generated by DB 
Service module 2029 and utilized by a number of other 
modules in access filter 203. The files are designed to make 
the following operations as efficient as possible: 
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Map from user identification to user group(s); 
Map from information resource to information set(s); 
Find policies that are associated with user groups; and 
5 Find policies that are associated with information sets. 
Components related to Authentication 

Evaluator 2036: Evaluator 2036 is a set of DLLs that are 
used by each proxy in proxies 2031. Evaluator 2036 pro- 
vides the following functions to the proxies: 
10 Prompting the user for further in-band or out-of-band 
identification information; 
Obtaining out-of-band authentication information from 

the Authentication Tool Service (ATS);. 
Obtaining the certificate associated with the current user 
is from SKIPd; 

Reading the MMFs 2301 and determining whether the 
access policies permit the user to access the resource; 
and 

20 Implementing the trust/sensitivity calculations for the 
path if access is otherwise allowed, including deciding 
whether access may be allowed via the path and if so, 
what encryption and authentication is needed and 
which access filter is nearest the server. These functions 
25 are performed by a component of evaluator 2036 
termed the VPN manager. 
Authentication Tool Service/User Identification Client 
(ATS/UIC) 2039 and 2041: 

ATS 2039 is the server in a client-server application that 
30 gathers and authenticates user information. ATS 2039 runs 
on the computer upon which the other components of access 
filter 203 are running. The client part is UIC 2041, which 
runs on Windows-based clients. ATS 2039 and UIC 2041 are 
the mechanism by means of which access filter 203 obtains 
35 out-of-band authentication information. ATS 2039 and UIC 
2041 communicate by means of a session which is separate 
from the session being authenticated. ATS 2039 gathers and 
caches the authentication information it obtains from the 
UIC clients and provides it to Evaluator 2046. The cached 
An information from the clients includes 

40 

Windows ID; 
Identity Certificates; and 
Authentication token ID's. 
SKIPd 2037: 

45 Most of SKIPd's functions are in support of SKIP 2021. 
Those functions include: 

Exchange of certificate information with other commu- 
nications partners. This is done through the use of the 
Certificate Discovery Protocol (CDP). 
Calculation of the Diffie-Hellman shared secret. This 
shared secret is key to the operation of SKIP. This 
calculation can take a considerable amount of time and 
is saved to disk in an encrypted form. 
55 Calculation of the transport key used to encrypt the 
session. These keys last for a period of time or amount 
of data. 

In addition, SKIPd will provide certificate matching cri- 
teria to the Evaluator(s) for use in user identification. 
60 Proxies 2031 

As previously explained, a proxy is software in filter 203 
that intercepts traffic for a particular protocol. The proxy 
'understands' the protocol that it is intercepting and can 
obtain the information required to identify the resources 
65 being accessed and/or to authenticate the user from the 
messages that are being exchanged during the session. All of 
the proxies but SMTP receive messages on ports other than 
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the standard ports for their protocol, with the IP filter Real Audio: The Real Audio proxy allows clients to 
redirecting messages using a given protocol from its si an- access real audio servers that are protected at the server level 
dard port to its non-standard port. The proxy provides the only. The real audio protocol utilizes a standard TCP socket 
information it has obtained from the session to evaluator connection to establish a session, but then uses a return UP 
2036 to decide whether the user has access to the informa- 5 channel. As with FTP, the real audio proxy has an interface 
tion resource. If the user does have access, access filter 203 to » ^ ter 2019 that permits it to indicate to IP filter 2019 
forwards the incoming messages to the server to which they ^i^^ ^JST* 1 'i H 1 ?^" , o ♦ 
are addressed and the messages are processed further in the . The SM1P (Simple Mad Transfer Protocol) ob- 
server by the service for the protocol In the following, each fets from ^^"P™ "^S S pr °wl 

c . J . , \ a - c a ~\~a- \ ♦ -o are not used to redirect traffic to the SMTP proxy. Whereas 

of the protocols employed in a preferred embodiment is 10 , • * . , , ^ t p.™, 

,. j c „u j f „ * _ i the other proxies listen on a non-standard port, the SMTP 

discussed; of course, other embodiments may include prox- / . t , , A \ u , 

es for other protocols proxy listens on the standard port (25) and then makes its 

Pr ipf: Tie majority of network traffic occurs over a own connections to the standard SMTP server software. The 

smalfnurnber of protocols for which there are proxies in access P° ,,cies ,n database 301 mus " ex P ,lcltl y aMow ,his 

access 

access filter 203. However, even where there is no proxy, an 15 _ * __„ ._ . _ T _ r c . 

access decision must be made. In some cases, the decision , I"»Mip: When a user species the URL for the 

can be made at the kernel level by IP filter 2019; when it Imr f Ma P • re P° rt mana f ' 20 ' downloads the IntraMap Java 

.u iDfli, nnin „ m & „ tn ;„f „,u;^u applet and the downloaded applet attempts to make a 

cannot be, IP filter 2019 provides the traffic to pr_ipf, which ^ c * «i. *m »u . u 

. , . r . . . . , .. connection back to a socket or the access filter 203 that has 

obtains whatever information relative to user identification ~^ " ™: ^ n 7i , 

and information resources it can from the traffic and passes 20 Xn T" 8 *. T *Z V, \ ,1 h 

the information to evaluator 2036 to determine whether 203 (0 intercepts the attempt to make the connecUon and 

access should be granted. Pr_J P f is not truly a proxy, since E° vldes 11 10 me P rox / on , 1 ° cal ■«*« f" m ® 

it only makes an access determination for IP filter 2019 and ™ e P™? responds* quen« from the applet by finding he 

does not pass any traffic to standard protocol software. answers f * e locil ^ of Cubase 301 and returning the 

FTP: The FTP proxy handles TCP/IP packets for the File 25 "f^ ■ 1PP ' "VfT'L 8 , 

Transfer Protocol In a present embodiment of VPN 201, reflecl me 8 «f CMB nghlS - ^ IntraMa P P roxv « " 

, . . , i j * *u * /i \ i t true proxy in that the entire connection is always completely 

access control is only enforced to the account (logon) level; . .v.- ~ , _ , , *i_ ; ■ . 

*u , ; „ . M , A „ , _ fl . serviced by the instance of the IntraMap proxy that inter- 
in other embodiments, access may be controlled to the tile J r r * 

access level. During the FTP logon portion of the protocol, ^^1° 2033 

the proxy determines the server and account being accessed 30 ]*~ ."^ u , G t ____ . . . u 

j . j »l. • * c *• * i * mir* --^ Anti-virus module 2033 m a preferred embodiment is a 

and provides this information to evaluator 2036 to determine . £ rx T T -jjl^ jw • i 

. f, it _ . , u u set of DLLs provided by Trend Micro Devices, Inc., 

whether the user belongs to a user group whose members _ . tl _ . j- . • a % 

■ r * * ^ v Cupertino, CA. In other embodiments, anti- virus modules 

may access the information sets corresponding to the e ^ * . , . . , _ n __ 

account. The proxy further handles the in-band authentica- &om other sources may be used Anli-Vuus module 2033 

tion using tokens in interactions with the user that are 35 check l aU k da,a enter !? g f V ^ 2 " X for , viruses ' In ord 5 r ,'° 

specified in the FTP protocol. P rov, f 1,561 wi h feedback on the progress of the 

FTP is actually a very complex protocol, involving both and t0 P reve °' ^.f" ^ent program from tuning 

an active and passive mode (Jed in Web browsers and some out ' the ^ 15 ^nsferred to the chent and is copied at the 

automated FTP clients). In addition, FTP data transfers ^ hme ml ? » 'TP 0 ^ ffle ^ "rus checkmg. The 

,. v j i • n j ♦ • j tv'd • v last portion of the data, however, is not sent to the client until 

utilize a second, dynamically determined TCP session. This 40 . . * ' 

requires a special interface between the FTP proxy and IP after ™» checklD S ™P le t te " ^ ^ f the ^ V P °T 

Filter 2019 so that the FTP proxy can indicate to IP filter *. ™ the temporary file, the temporary file is checked for 

- ft1fl t , t „ 11rt „, ( L fl eocc - „ viruses. If no viruses are detected, the remainder of the data 

2019 that it should allow the second session. , t . A TJ . . . c ...... r * 

„™ ™ • u £. _ «i ^ is sent to the chent. If a virus is found, then the transter is 

HTTP: The HTTP proxy is built from the source code for , , _ , . 4 . ^ c 

. tf j or,,,;, , 4 # . f iiT r pn a aborted. In a present embodiment, the user is notified of a 

the public domain CERN implementation of HTTP and 45 e „ , *\ , . . ' . . 

contains aU of its caching logic. THe proxy uses evaluator transm^on. If an administrator has so specked, an 

2036 to check each access to a URL. No in-band authenti- ? lert 7* ** «° Z^™*?*!- 

cations are performed with HTTP. Uunch, Log, Alert and Reports 2027 

Telnet: The Telnet resource is only controlled to the server ^ *>*P°™* of this module perform the following 

level due to the non-standardized nature of Telnet logins. 50 c l0ns * 

The Telnet proxy is only used in order to provide additional Launch^ontrols the initial sequence of startup tasks that 

in-band authentications. It is the simplest of the true proxies. takes place on an access filter 203 when VPN 201 is 

NNTP: The NNTP (Network News Transfer Protocol) is established, 

used to control both news feed and news reading operations. Logs— a DLL that provides a standardized logging lnter- 

During the feed operation, the NNTP proxy watches for 55 ^ ACC - 

uuencoded messages. These are binary messages that have Alerts — a standalone program that watches all of the NT 

been translated into ASCII text for the purposes of trans- logs, looking for alert conditions specified in database 

mission. Such messages are often broken up into multi-part 301. The method by which an alert is delivered is 

messages to keep them to a reasonable size. The NNTP specified using the GUI for defining alerts, 

proxy caches all parts of binary messages. For each such 60 Reports^ — a subset of the logs are forwarded to a special 

message, if that message is the last part that will complete report log, concentrated into a database and later for- 

a multi-part message, then the entire multi-part message is warded to Report Manager 209. 

assembled and anti-virus 2033 checks it for viruses as Administrative Graphical User Interface 1915 

described in more detail below. During the news reading The GUI may run on access filter 203 or on any computer 

operation, access is protected to the news group level. As in 65 having a 32-bit Windows brand operating system that is 

other proxies, evaluator 2036 is used to determine if the attached to access filter 203. Whether the GUI runs on access 

current user may access the news group. filter 203 or on an attached system, it utilizes ISDB MAN- 
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AGER 2027 to read from and write to a working copy 1903 is computed according to the MAC algorithm identified in 

of access control database 301. All necessary modifications field 2226 and which is used by access filter 403(3) to verify 

to access control database 301 are made through GUI 1915. that the message arrived without tampering. 

An 'apply' operation in the GUI is sent as a signal to PCS Encrypted payload 2227: Encrypted payload 2227 con- 

2025, which responds to the signal by starting the 5 tains the encrypted message which roamer 503 is sendmg to 

previously-described distribution and synchronization server 407, deluding IP header^31 for that message and 

operation encrypted message 2229. IP header 2331 has the IP address 

Detailed Example of Operation of Access Filter 203: FIGS. for 407 an * te P^J^ 1 * 1 f ° r * he HTIP protocol 

5 and 22 service. Encrypted payload 2227 can be decrypted by using 

In the following, the end-to-end encryption example of 10 Kp22g with the decryption algorithm specified by CRYPT 

FIG. 5 will be explained in detail. In that example, a roamer ,, ... " ,„ „„, 

503 whose PC is equipped with SKIP is accessing a SKIP- H » n ^S SKIP Message 2201 ,, ,-, f ,«,, r 

equipped server 407 inside a site on VPN 201. When roamer S ™ Jf"^?? ""^ ^ T V„ 

-n/ r . t , mK nni •« « * a access filter 403(3). Processing of the message begins at the 

503 was set up to access VPN 201, it was set up to do so via 0 ™ , , i - . , of™* mi* 5 » • 

access filter 403(3) using a particular type of encryption. « fT,TJ.P,n,T f, 

Here, it will be assumed that the type of encryption being ^ *» fKIP2021, which in turn recogmzes from MT field 

used by roamer 503 has a trust level of "secret" and that the 220 « that «»» messtg* is a SKIP message. To decrypt and 

user wishes to access a Web page on server 407 that has a ■r^m^iTti^^i^n'Sm 

sensitivity level of "secret". Since what is being accessed is * J" * ? 17, 

a Web page, roamer 503 is using the HTTP protocol for its 20 2215 > and DMKID2213 to SKIPd 2037 winch uses the IDs 

session with the HTTP service on server 407. Since roamer *I™ ve '^f^^ for roamer 503 and access filter 

503, the access filters 203 in VPN 201, and server 407 are f 83 ®" ^ om c ™,^ S ^ " * T^T 

aU equipped with SKIP, they are all provided with their own 15 n °' lh«e, SKffd 2037 uses the CDP protocol to fetch the 

„,,.,■„ „„. ■ ,„,„ , „ A , ; „:„:„„„ , „ eni ,io„ h.. certificate. The information in the certificates is then used 

public and private keys. At a minimum, roamer 5U3 also has ... AM ,m . , 

fu .-a . j ui- i f ci... Aai/i\ together with access filter 403(3) s private key to create a 

the certificate and public key for access filter 403(3) to 25. 6 . u-l-.u j.j .. 

which it directs messages for servers internal to VPN 201; f a, * d '£« va } ue * w *" ch * "*? , used 1 to ^P 1 transport 

access filter 403(3) hat the certificate and public key for ^ K P 22Zi ™ d 10 P^uce two internal keys, Akp «nd I Hep. 

roamer 403 (or obtains them using the Certificate Discovery SHP Mves me shared *»* for u * ^ fature 

Protocol); all access filters 203 in VPN 201 have or can get messages^ since itt computation takes a sigmficant amount 

each others' public keys and the public keys for servers in 30 of tune " Ne *' a ™£ C * ram P u * d ^J^S?" 

VPN 201 that are equipped with SKIP. Additionally, each m !^ a f, e ,*f , d me " mlh ^2221 

access filters 203 in VPN 201 knows the IP addresses of all ^ 2226 ««« message 2201 has not been 

of the other access filters 203 and servers in VPN 201. >f m P ered wlth - If * at f 5 *° «£• *>* ke y * ^ ,0 , 

Allofthemessageswhicharesentandreceivedaspartof decT ™ 1 f 01 ™ 1 * pay i° ad 2227 ° ^ver the original 

the HTTP session between roamer 503 and server 407 are 35 messa ^ tom ' 0amer ,^ 3 - De "yP ted 227 ,S ^ 

encrypted and authenticated by SKIP. FIG. 22 shows the P rovld ^, «P IP filter 2019, which applies its rules to the 

r . i u u crm ' M ni oittd source IP address, destmation IP address, and port number of 

form taken by such a SKIP message 2201. The SKIP T _ , , . . . \ ncu 1ftin 

v mn A„ k„ mDc^w^ ~„tUo clfCtom „,u:„u ,v IP header 2231. If no rule denies access, IP filter 2019 

message is made by 5>KJr software on the system which is _ , , , 

t u» <™7.™ n ptu- cvid ci^id ™^ ' D -i-jni <^„,„ follows another rule and redirects the unencrypted message 

the source of the SKIP message. SKIP message 2201 shown , . _ „ T _ ¥ _ „ , „, „„ n : _ r 

here is from roamer 503. Its main components are: 40 °S e ££T h SNS, £ ^ MHD ,? 17 ,S ! ,he P °S f ° r 

Outer IP header 2203: Outer IP header 2203 is used to ^ "Sf "J 9 , "fn f «™ CxP ° Ii - 

defiver the SKIP message to access filter 403(3). Contained ToProxyPortF.le of MMFs 2301 to find the port in quesnon 

. in u a a~- « - id ->iao <v.. Processing continues at the application level in user level 

m outer IP header 2203 are a source IP address 2209 tor - rfVrt « *. . • trT ™ , . . . 

- A1 j * i • . ■ Tn , i nnc A „„ 2003 of the operating system. The HTTP proxy has in hand 

roamer 503 and a destmation IP address 2206 for access i L 5rt. 

filter 403(3). Destination address 2206 used by roamer 503 45 ^ e ****** ^f^™' ^ P^.? unb "° f lhe SCIV «' 

was set lo specify access filter 403(3) when roamer 503 was me UR , L for the P a f • the ^ to °S«« *c 

set up to ac£ss VPN 201. Source IP address 2209 may be user of ^ amer 503 and the encryption method used to 

dynamically assigned to roamer 503 by the Internet service ^ message It wiU use ^valuator 2036 to determine 

provider that roamer 503 uses to connect to Internet 121. me ^llowuig from the MMF files 2301: 

Outer IP header 2203 further contains a message type (MT) 50 the ^ &™V* that me ^ represented by the certificate 

field 2208 which specifies that the message is a SKIP belongs to; 

message. ^ G information sets that the Web page belongs to; 

SKIP header 2205: SKIP header 2205 contains the infor- whether there is an access policy that permits at least one 

mation needed to decrypt SKIP message 2201 when it is of the user groups to access at least one of the infor- 

received. SKIP header 2205 contains at least a destination 55 mation sets; and 

NSID 2215 and destination MKID 2213 for the destination's whether the trust level of the message is at least equal to 
certificate, that is, the certificate for access filter 403(3), and the sensitivity level of the Web page, 
the source NSID 2219 and source MKID 2217 for the Beginning with the first of these tasks, e valuator 2036 
source's certificate, that is, the certificate for roamer 503. In receives the NSID and MKID for the certificate and uses the 
addition, SKIP header 2205 contains identifiers for the 60 certificate matching criteria from the certificate with the 
algorithm used to authenticate the message (MAC ALG DBCertificatesByUserGroupFile to obtain the identifiers for 
2226) and the algorithm used to encrypt the message the user groups the user sending the message belongs to. 
(CRYPT ALG 2225), as well as an encrypted transport key Evaluator 2036 determines the information sets by taking 
for decrypting the message (Kp 2223) and an identifier 2224 the IP address of the server, the port number of the service, 
for the algorithm used to decrypt the transport key. 65 and the URL for the Web page and using the IP address with 
Authentication header 2211: Authentication header 2211 the DBServerlDBylPFile to determine the server that con- 
contains a MAC (message authentication code) 2221, which tains the Web page, the port number with the DBService- 
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IDByPortFile to determine the service on the server that 
provides it, and the URL with the DBResourcelDbyName- 
File to get the identifier for the resource in database 301, and 
then uses the DBResourcesByResourcelDFile to get the 
identifiers for the information sets that the Web page belongs 5 
to. 

With the identifiers in database 301 for the user groups 
and information sets in hand, evaluator 2036 uses the 
DBResourcesFile to determine whether there is an access 
policy which permits any of the user groups that the user 10 
belongs to access any of the information sets that the Web 
page belongs to. In so doing, it may only consider user 
groups whose membership is determined using modes of 
identification whose trust levels are sufficient for the 
resource's sensitivity level. The DBResourcesFile maps 15 
each information set identifier to a list of the user groups for 
which there are access policies involving that resource set. 
For each user group, the DBResourcesFile further indicates 
whether the policy allows or denies access. Evaluator 2036 
uses the DBResourcesFile to determine for each information 20 
set in turn that the Web page belongs to whether the list of 
user groups for which there are access policies with regard 
to the information set includes one of the user groups to 
which the user belongs. If there is an access policy for any 
of the user groups that denies access, the evaluator indicates 25 
to the HTTP proxy that access is denied; if there is no access 
policy for any of the user groups that denies access and at 
least one that allows access, the evaluator indicates to the 
proxy that access is allowed; if there is no access policy of 
any kind for any of the user groups, the evaluator determines 30 
if there is at least one certificate or token based user group 
that has an allow policy for the resource. If so, and the 
requesting client has a UIC running, then the UIC is con- 
tacted to ask the user for additional identity information; if 
additional identity information comes back, the process 35 
described above is repeated. Otherwise, the evaluator indi- 
cates to the HTTP proxy that access is denied. 

Of course, evaluator 2036 will also deny access if the 
access request does not have a trust level equal to the 
sensitivity level of the Web page. Evaluator 2036 obtains the 40 
sensitivity level of the Web page from the 
DBResourcesByResourcelDFile, the trust level of the user 
identification from DBTrustAuthenticationsFile, and the 
trust level of the encryption method from the DBTrustEn- 
cryptionsFile. Since SKIP has encrypted the message with a 45 
method that has the "secret" trust level, the trust level of the 
path through the network is not of concern in this example. 
To determine whether the trust levels for the user identifi- 
cation and the encryption method are sufficient for the 
sensitivity level of the Web page, Evaluator 2023 uses the 50 
DBTrustTableFile, which effectively implements SEND 
table 601. If the trust levels are sufficient, Evaluator 2036 
indicates to the proxy that the access is allowed. 

Once the proxy has confirmed that access is to be allowed 
to the information resource specified in the message, the 55 
proxy originates a new session to the actual service, the 
HTTP service on server 407. Proxy 2031 sends a special 
message to IP filter 2019 telling it to allow the specific 
session through, since otherwise this session would probably 
be blocked by rules or sent again to a proxy. The message to 60 
IP filter 2019 also includes information about the encryption 
needed for the new session, which in this example is that the 
session should be encrypted to the final access filter 403(5) 
and should use encryption suitable for the data sensitivity 
level, which is secret. When IP filter 2019 encounters the 65 
new session, it finds that it matches the criteria specified by 
proxy 2031, so it passes the session to SKIP. Since encryp- 
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tion is needed for this session, the message will be reen- 
crypted. SKIP 2021 creates a SKIP message 2201 in the 
same fashion as described above, except that: 

Outer IP header 2203 for the message specifies access 
filter 403(3) as the source of the message and access 
filter 403(5) as the destination; 
SKIP header 2205 has SNSID 2219 and SMKID 2217 for 
access filter 403(3) and DNSID 2215 and DMKID 
2213 for access filter 403(5), and the other values in 
header 2205 are also those required by the fact that the 
source and destination for the message are now access 
filter 403(3) and access filter 403(5); 
Encrypted payload 227 is the same as before (except that 
it has been encrypted using a different key) and MAC 
2221 is produced as required for entire new message 
2201. 

As the proxy is relaying the message it is also watching 
for file transfer types that might contain viruses. When it 
encounters one, it applies anti-virus software 2033 to these 
files. If a file contains a virus, the proxy fails to deliver the 
complete file, thereby rendering the virus harmless. If access 
control database 301 so indicates, the proxy sends an alert 
when anti-virus software 2033 detects a virus. 

As new SKIP message 2201 is received at access filter 
403(5), it is passed to SKIP 2021, where it is authenticated 
and decrypted as described previously. By the same mecha- 
nism as described above with regard to access filter 403(3), 
IP filter 2019 on access filter 403(5) recognizes that the 
message is destined for the HTTP application protocol, so it 
directs it to HTTP proxy 2031. That proxy accepts the 
message, then sends information it can obtain about the 
message's originator (access filter 403(3) from outer IP 
header 2203 and SKIP header 2205 to evaluator 2036 to 
determine whether the session being instigated by this 
message should . be allowed to proceed. Evaluator 2036 
examines the source IP address of the message as well as the 
other identity information, and by looking up the source IP 
address in the MMF file DBServerlDBylPFile, determines 
the identifier in data base 301 for access filter 403(3), uses 
that identifier to locate access filter 403(3)' s certificate, and 
finds that certificate information matches the retrieved cer- 
tificate associated with access filter 403(3)*s message being 
processed. The source of the message, access filter 403(3), 
is thereby recognized as an access filter 403 within VPN 
201, so evaluator 2036 responds that the session should be 
allowed, for the reason that it is a message already permitted 
by another access filter 403 within the same VPN 201. This 
decision to allow the message is returned to the http proxy 
2031. The evaluator 2036 will instruct http proxy 2031 on 
access filter 403(5) to allow any request that comes over the 
same session, for the same reason. As the http request is 
processed, the proxy will establish an outgoing connection 
to the http service on server 407, in the same manner as the 
outgoing session was established on access filter 403(3). 

When the connection is initiated to server 407, evaluator 
2036 looks up the IP address of server 407 in the MMF file 
DBServerlDBylPFile to determine the identifier in database 
301 for server 407, uses the identifier to locate the table for 
the server, and uses the certificate identifier from that table 
and the DBCertificatesFile to find the certificate for server 
407. Then it uses the keys for access filter 403(3) and the 
public key for server 407 (obtained from the certificate) to 
construct a SKIP session as described previously. The actual 
message is encrypted and authenticated, a SKIP header 2205 
is added, and an outer IP header 2203 is added, directing the 
message to server 407. 

When the message reaches server 407, SKIP in server 407 
checks the authentication on the message, decrypts it, and 
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forwards the decrypted message to the HTTP service, which 
performs the access to the Web page requested by the 
message contained in the payload. Having obtained the Web 
page, the HTTP service makes a return message with an IP 
header specifying roamer 503 as the destination. This return 
message is then encapsulated in a SKIP message 2201 as 
previously described. This SKIP message is directed to 
access filter 403(5) and contains the information in outer 
header 2203 and SKIP header 2205 that is required for a 
message between those entities. 

When the reply message reaches access filter 403(5), it is 
authenticated and decrypted by SKIP 2021 there, and for- 
warded to IP filter 2019. The message is found to match an 
existing session so evaluation is not needed; it is forwarded 
directly to HTTP proxy 2031. There it is checked for validity 
as an HTTP protocol reply message and retransmitted back 
to the originator of the HTTP session, which is access filter 
403(3). Checking by the anti-virus module 2033 is not done 
since the originator of this session is known to be another 
access filter 403 in the VPN 201, as it is known that access 
filter will do the checking if needed. The retransmission of 
the reply is again processed through SKIP 2021 and 
encrypted as above, using the SKIP parameters required for 
an exchange between access filter 403(3) and access filter 
403(5). 

When this reply message reaches access filter 403(3), 
precisely the same thing occurs, that is, the message passes 
through SKIP 2021 and IP Filter 2019, to the http proxy 
2031. There it is checked for validity as an HTTP protocol 
reply message, possibly passed through the anti-virus mod- 
ule 2033 (if the message content type warrants it), and 
retransmitted back to the originator of the HTTP session, 
which is roamer 503. The transmission of the reply is again 
processed through SKIP 2021 and encrypted as above, using 
SKIP parameters as set forth above for a message being sent 
from access filter 403(3) to roamer 503. The reply message 
is then received at roamer 503, where it is authenticated and 
decrypted by SKIP, provided to the user's browser, and 
displayed for the user. 
Conclusion 

The foregoing Detailed Description has disclosed to those 
skilled in the arts to which the Detailed Description pertains 
the best mode presently known to the developers of the 
access filters disclosed herein of constructing and using 
access filters that overcome the scalability problems which 
prior-art prior-art access filters presented for virtual private 
networks. The scalability problems are overcome by a 
number of features of the access filter disclosed herein. 
Among them is an access control database which permits 
delegation of administrative authority and administration of 
a local copy of the access control database and thereby 
allows decentralization both with regard to administrative 
personnel and with regard to geographic location. The 
access control data base specifies access policies that deter- 
mine which user groups may access which information sets, 
policy maker policies that determine which user groups may 
make access policies, and administrative policies which 
determine which user groups may administer objects in the 
virtual private network. It is these administrative policies 
which permit easy delegation. 

Administrators can employ the graphical user interfaces 
disclosed herein to administer the access control data base. 
The clarity and ease of use of these graphical user interfaces 
makes it easy to delegate administrative authority to non- 
specialists. When an administrator makes a change in the 
access control data base, the change is first made in the local 
copy of the data base for a given access filter and then 
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propagated to the local copies of the other access filters. The 
local copy of the access control database also makes it 
possible to efficiently implement a graphical user interface 
to the virtual private network which shows a user only those 
resources that belong information sets to which the user 
groups to which the user belongs have access. 

Another feature of the access filter which contributes to 
scalability is the ability of the access filters in a virtual 
private network to authenticate sessions to each other. 
Because the access filters can do this, access checking of a 
request need only be done once, at the first access filter 
encountered by the request. The other access filters between 
the user and the information item need only determine 
whether the request has already been authenticated by 
another access filter, and if it has, pass the request through. 
Authentication of sessions by the access filters to each other 
thus both decreases the amount of access checking that need 
be performed and distributes the access checking that is 
done throughout the virtual private network. 

Authentication also permits encryption to be done in the 
same fashion: the first access filter encountered by the 
request encrypts the request after it has checked the access, 
and the other access filters pass the encrypted request 
through without decrypting it until the last access filter 
before the server that contains the data item being accessed 
by the request is reached. Doing encryption and decryption 
in this fashion reduces the amount of encryption and decryp- 
tion and distributes the encryption and decryption that is 
done in the same fashion as with access checking. 

Another feature is that the access filter assigns a sensi- 
tivity level to an information set and a trust level to a mode 
of identification of a user making a request and permits the 
access only if the trust level is at least as great as the 
sensitivity level. In the preferred embodiment, identification 
by Internet address is assigned a low trust level and identi- 
fication by cryptographic authentication with an X.509 
certificate is assigned a high trust level. If the identification 
used by the user in making the request does not have a trust 
level sufficient for the sensitivity level, the access filter can 
interactively request that the user provide identification with 
a higher trust level. 

The access filter also assigns trust levels to segments of 
the actual networks in virtual private network 201 and to 
encryption algorithms. The access filter analyzes the trust 
levels of the network segments between the user and the 
server that contains the information item, and any of them is 
lower than the information item's sensitivity, the access filter 
requires that the session be encrypted with an encryption 
algorithm whose trust level is at least as high as the 
information item's sensitivity level. If a segment between 
the user and the first access filter or a segment between the 
last access filter and the server does not have the requisite 
trust level, the first access filter requires that the user or 
server encrypt the session with an encryption algorithm that 
has the requisite trust value before it will allow access; if a 
subsetment of the segment between the first access filter and 
the last access filter, the first access filter itself encrypts the 
session using an encryption algorithm that has the requisite 
trust level. By requiring only the trust level necessary for an 
information item's sensitivity, the access filter reduces the 
burden of access checking to what is actually required for 
the information item; by permitting the user to offer a more 
trustworthy identification and using encryption to upgrade 
the trustworthiness of a segment of the network, the access 
filter provides flexibility without compromising security. It 
should be noted that in other embodiments, the first access 
filter may encrypt the session as required for the server, 
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providing of course that the encryption for the server is 
sufficient for the trust level of the resource. 

While the Detailed Description has disclosed the best 
mode presently known to the developers of implementing 
the above features, it will be immediately apparent to those 
skilled in the arts relating to access filters that any number 
of other implementations which embody the principles 
embodied in the access filter disclosed herein are possible. 
For example, as pointed out in the Detailed Description, an 
access filter with the above features may be implemented as 
an application running under an operating system, as a 
component of an operating system, and/or as a component of 
a router. Since an unlimited number of other embodiments 
of the principles disclosed herein are possible, the Detailed 
Description is to be regarded as being in all respects exem- 
plary and not restrictive and the breadth of the invention 
disclosed herein is to be determined not from the Detailed 
Description, but rather from the claims as interpreted with 
the full breadth permitted by the patent laws. 

What is claimed is: 

1. An access filter which is used as one of a plurality of 
access filters in a network, the access filter serving to make 
a determination whether a request for access by a user to an 
information resource will be permitted and the network 
further including a client from which the user makes the 
request via a path in the network that includes at least one 
of the acess filters and a server that provides the information 
resource in response to the request, the access filter com- 
prising: 

a local copy of access control information that indicates 
whether the user may access the resource; 

an access checker which employs the local copy to make 
the determination; and 

an access check confirmer that determines whether 
another access filter in the path has already made the 
determination and only causes the access checker to 
make the determination if no other access filter has 
done so. 

2. The access filter set forth in claim 1 further comprising: 
an encrypter/decrypter for encrypting and decrypting the 

request; and 

when the determination is that the request will be 
permitted, the encrypter/decrypter encrypts the request. 

3. The access filter set forth in claim 2 wherein: 

each of the access filters has a key for encrypting requests 
to be decrypted by the access filter; 

each of the access filters has routing information from 
which the last access filter in the path can be deter- 
mined and key information which gives the access filter 
access to the key belonging to the last access filter; and 

when the access filter is the other access filter, the 
encrypter/decrypter encrypts the request using the key 
belonging to the last access filter. 

4. The access filter set forth in claim 2 wherein: 

the encrypter encrypts the request such that the request 
can be decrypted by the encrypter/decrypter in the last 
access filter in the path. 

5. The access filter set forth in claim 4 wherein: 

the encrypter can encrypt the request according to a 
plurality of encryption methods; 
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the access control information associates a sensitivity 
level with the resource and a trust level with each of the 
plurality of encryption methods; and 

the encrypter encrypts the request using an encryption 
method of the plurality such that the trust level of the 
encryption method is at least equal to the sensitivity 
level of the resource. 

6. The access filter set forth in claim 2 wherein: 
) the client encrypts the request; and 

the access filter employes the encrypter-decrypter to 
decrypt the request prior to making the determination. 

7. The access filter set forth in any one of claims 1 through 
6 further comprising: 

' an authenticator for making an authentication for the 
request; 

when the determination is that the request will be 
permitted, the access filter employs the authenticator to 
) produce authentication information that authenticates 
the request and adds the authentication information to 
the request; and 
the access check confirmer determines from the added 
authentication information whether another access fil- 
' ter has already made the determination. 

8. The access filter set forth in claim 1 further comprising: 
an editor for making a change in the local copy of the 

access control information; and 
30 a change propagator for propagating the change to others 
of the plurality of access filters. 

9. The access filter set forth in claim 8 wherein: 

the access control information further indicates whether a 
given user may make a change in a predetermined part 
35 of the local copy; and 

the access checker further employs the local copy when a 
user employs the editor to make a particular change to 
make a determination whether the user is permitted to 
40 make the particular change. 

10. The access filter set forth in claim 9 wherein: 

the access control information further permits a given user 
who may make a change in the predetermined part to 
delegate making the change to another user. 
45 11. A data storage device for use in a system including a 
processor, the data storage device being characterized in 
that: 

the data storage device contains code which, when 
executed in the processor, implements the access filter 
50 set forth in claim 1. 

12. The access filter set firth in claim 1 wherein: 
the access filter is implemented as an application program 
executing under an operating system. 
55 13. The access filter set forth in claim 1 wherein: 

the access filter is implemented as a component of an 

operating system. 
14. The access filter set forth in claim 1 wherein: 
the access filter is implemented as a component of a router 
60 in the network. 

* * * * * 
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